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, so nothing changes until you turn one off.

• 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; previously each page carried its own permission.

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

• The list offers 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.

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

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 now sit under one Assist heading instead of two separate ones. 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 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 💡

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