> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/workspace/roles-and-permissions.md).

# Roles & permissions

Siit separates people who run operations from everyone else. Employees submit requests in Slack/Teams or the Portal. Admins work those requests in the Admin console with role‑based access.

#### User types

* Employee
  * Can submit and track requests in Slack/Teams and the Portal.
  * No access to the Admin console.
  * Auto‑provisioned from your directory sync.
* Admin
  * Works in the Admin console (Inbox, Workflows, Reporting, Settings) based on an assigned role.
  * Must be explicitly invited.

Important only Admins need an invite to the Admin console. Employees are created automatically and can use Slack/Teams/Portal without an Admin seat.

#### Built‑in roles

* Owner
  * Full control of the workspace, billing, security settings, and data residency. Can manage roles, delete the workspace, and approve critical app connections.
* Super Admin
  * Full product admin (all features, all data), excluding billing deletion safeguards reserved to Owners.
* HR Admin
  * Focused access to HR services/inboxes, knowledge, and workflows. Typically can see and work private HR requests. No access to IT‑only data unless granted.
* IT Admin
  * Full access to IT services/inboxes, integrations (Okta, MDM, SaaS), playbooks, and workflows. No access to HR‑only content unless granted.
* Finance Admin
  * Access to Finance services, knowledge, and reporting. No access to IT/HR content unless granted.
* Ops Admin
  * Access to Workplace/Operations services and assets; limited settings beyond their scope.
* Custom
  * Create your own role with fine‑grained permissions and data scopes.

#### Permissions control

* Features
  * Requests (view, reply, internal notes, resolve/merge, delete), Services, Inboxes, Workflows, Communications, Resources (Articles, App Library), Reporting, Integrations, Portal, Office hours/SLAs, Tags, Templates, Satisfaction surveys, Agents (AI).
* Data scope
  * Which inboxes/services the admin can see and act on.
  * Visibility to private requests by team/service.
  * People/PII fields and custom fields that are visible/editable.
* Actions
  * Who can change status, reassign, set priority/tags, add/remove participants, send approvals, run webhooks, manage connectors, publish articles, manage portal audience, and run AI playbooks.

Scoping examples

* HR Admin: Access only HR inboxes and services; can view private HR requests and payroll fields; cannot open IT workflows or device data.
* IT Admin: Can manage Okta/Jamf connectors and playbooks; cannot view HR private threads or payroll fields.
* Auditor (Custom): Read‑only access to Reporting and Requests without PII fields.
* Team Lead (Custom): Full access to a specific inbox, limited access to global settings, can manage templates and tags for their team.

**How to add an Admin or Owner**

1. Go to Settings → Roles & permissions.
2. Click New.
3. Choose a role (Owner, Super Admin, HR/IT/Finance/Ops Admin, or Custom).
4. If Custom:
   * Select features they can access.
   * Set data scope (inboxes/services, private vs. public).
   * Choose which fields they can view/edit.
5. Invite the user (email). They’ll sign in with SSO.
6. Save. Changes apply immediately.

#### Managing roles

* Edit or revoke: Settings → Roles & permissions → select the user → Update or Remove access.

#### Best practices :bulb:

* Least privilege: start with HR/IT/Finance/Ops Admin presets and tighten scopes to only the inboxes/services needed.
* Separate duties: keep billing and workspace security with Owners; operational config with Super/IT/HR Admins.
* Protect sensitive data: restrict payroll/PII fields to HR Admins and specific Custom roles.
* Keep private private: grant “view private requests” only where necessary; default others to public‑only.
* Use Custom roles for leads: empower inbox leads to manage templates/tags without global settings access.
* Review quarterly: export current admins and confirm continued need; remove dormant access.

#### FAQs

* Can an Admin also be a requester? Yes—admins can submit requests like any employee.
* Do approvers need Admin seats? No. Any employee can approve; approvals are private and auditable.
* How do we limit access to specific services? Use role data scope to include only selected services/inboxes and toggle “view private” per scope.
* Can we hide specific fields (e.g., salary)? Yes—use field‑level visibility in the role to hide or make read‑only.
* What happens when someone leaves? Removal from your directory disables their Employee access; remove their Admin role in Siit to revoke console access immediately.