# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.siit.io/workspace/roles-and-permissions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.