> 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 employees, who submit requests in chat and the Portal, from admins, who work them in the console under a role. Admins need an invite, employees are provisioned automatically 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, Request behavior, Agents (AI), Assist, Settings (element by element, per category). * 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. Request permissions Two toggles sit under the `Requests` group of a role, alongside the view scope. Both are on by default, including on the built-in admin roles. * **Ability to archive request** — archive a request, on its own or through a bulk action. Turn it off and the role keeps working requests but can no longer archive them, from the request itself, from the bulk action bar, from the right-click menu, or through the API. * **Ability to open request from Siit admin dashboard** — create a request from the admin console. Turn it off and the role works the requests that reach it from Slack, Teams, email, and the Portal, without opening new ones itself. Use them for roles that should handle requests without closing the loop themselves, such as a first-line team that triages but never archives. Settings access * Each Workspace Settings category (Account details, Teammates, Roles & Permissions, Business calendars, Security, and so on) grants access element by element, not as a whole category. * A role with none of the elements in a category enabled doesn't see that category in its Settings menu at all. * The `Settings` category itself, which holds role and permission editing, stays available to the Owner role only. * `Request behavior` is one permission covering the three pages grouped under it: Requests automations, Request on behalf, and Satisfaction survey. Grant it once and the role reaches all three. External actions A role carries the integrations it is allowed to act in. Granting an integration allows every action Siit offers for it: the user actions in the request side panel, the equipment commands, ticket escalation, the integration steps of a workflow, the provisioning and deprovisioning actions of an app access role, and manual runs of a custom action along with their history. They all sit on one **External actions** tab of the role editor, under **Enabling external access**, as a switch per integration. * The tab lists the integrations you have actually connected — Okta, JumpCloud, Google Workspace, Microsoft Entra ID, Jamf, Intune, Kandji, Slack, Rootly, your ticketing tools, and each of your custom integrations. A workspace with none reads *No connected integrations offer external access.* * **Okta, JumpCloud, Google Workspace, Microsoft Entra ID, Jamf, Intune and Kandji** stay with the Owner and Super Admin roles, as they always have. * **Slack, Rootly and the ticketing tools** had no permission of their own before, so every admin role starts with them. No role loses anything it could already do. * **Custom integrations** go to your super admin roles only. Create one and it is granted to them automatically; grant it to another role to let that role use it. * An action whose integration has since been disconnected is refused rather than failing halfway through. Turning a switch off takes the actions away, not the configuration behind them. A workflow step, an app access role or a saved webhook that uses the integration keeps its identifiers, its inputs and its history, and keeps running. What the role loses is the ability to run that action by hand, to pick it in an editor, and to save a change to a step that uses it. A dialog left open when the permission changed re-checks before it submits, so nothing slips through a stale screen. Assist access Three permissions sit under the `Assist` group and gate the AI & Agents section of Settings. On the role editor's **AI Agents** tab, **Access Assist** and **Manage configuration** sit under one **Assist** heading. The heading always shows, because managing the configuration is always available; **Access Assist** only appears for workspaces that have Assist. * **Access Assist** — open Assist from the admin console and use it. On by default for every admin. * **Can manage Assist** — edit the workspace guidance and the **Allow external MCP** toggle in **Settings → AI & Agents → Assist**. Only an Owner can grant or revoke it, the same way the `Settings` category works. * **Can view Assist usage** — open **Settings → AI & Agents → Assist usage** and see consumption per admin. Any Super Admin can grant it. Personal instructions and personal MCP connectors in **Settings → Personal → Assist personalization** need no permission: every admin manages their own. That page, in the Settings sidebar and in the avatar menu alike, only shows for admins who hold **Access Assist**. See [Assist](/ai/assist.md) for what each setting does. Agent log access * AI Agent conversation logs follow the same data scope as requests an admin sees only the logs behind requests they can already access, not every log for an agent. * Set independently per role and per agent (IT Agent, Triage Agent, etc.): All, My assignments and inboxes, or None. * Optionally include AI conversations that never became a request, so scoped admins still see agent activity that didn't escalate. 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): Sees AI Agent logs only for the requests in their inbox, not every conversation the agent has had workspace‑wide. **How to add an Admin or Owner** 1. Go to Settings → Your team → 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. Search for the person by email. They don't have to exist in Siit yet: type a full address on one of your company domains and it appears as a **New user** row you can select. Siit creates the person, assigns the role, and sends the invitation in one step when you save. 6. Save. Changes apply immediately, and the new admin signs in with SSO. > **Note** - the **New user** row only shows for admins who also hold the user-management permission, and only for addresses on a domain your workspace owns. An address outside your domains cannot be invited. #### Managing roles * Edit or revoke: Settings → Your team → 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 This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.siit.io/workspace/roles-and-permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.