> 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/integrations/iam.md).

# IAM

### Why connect your IdP

Your IdP is the source of truth for **who has access to what**. Connecting it to Siit means:

* **A directory aligned with access.** Users, groups, and application assignments sync into Siit, so every request carries the full picture of the requester's access.
* **One-click actions from any request.** Provision, revoke, add to group, reset password, reset MFA, and more — directly from the request side panel, without switching tabs.
* **Workflow-driven provisioning.** Use IdP actions in any workflow: approvals, Day-1 onboarding, access requests, offboarding, SLA escalations.
* **AI Agent automation.** Let the IT Agent run sandboxed IdP actions inside playbooks, gated by approvals when needed.
* **Audit and traceability.** Every IdP action triggered from Siit is recorded on the request timeline.

### What Siit syncs from your IdP

By default, Siit imports:

* **Users** — identity, work email, status (active / suspended / deprovisioned)
* **Groups** — membership, so workflow conditions can match on group
* **Applications** — per-user app assignments and ownership
* **Lifecycle events** — user created, user suspended, group membership change

Work email is the canonical identifier used to match users across your IdP, HRIS, and other connected tools.

### Supported IAM platforms

Siit integrates natively with the four most common IdPs. Each one has its own setup guide:

* [Google Workspace](/integrations/iam/google-workspace.md)
* [Microsoft Entra ID](/integrations/iam/microsoft-entra-id.md)
* [Okta](/integrations/iam/okta.md)
* [JumpCloud](/integrations/iam/jumpcloud.md)

Using a different IdP? Reach out via in-app chat — we also support SAML SSO for sign-in from most providers (see SAML - SSO).

### Actions available per IdP

The specific actions Siit exposes vary by IdP. Here's what's available today:

| Action                         | Google Workspace | Entra ID | Okta | JumpCloud |
| ------------------------------ | ---------------- | -------- | ---- | --------- |
| Directory sync (users, groups) | ✓                | ✓        | ✓    | ✓         |
| Add / remove from group        | ✓                | ✓        | ✓    | ✓         |
| suspend / Unsuspend user       | ✓                | —        | ✓    | ✓         |
| Reset password                 | ✓                | —        | ✓    | ✓         |
| Reset MFA                      | —                | —        | ✓    | ✓         |
| Add / remove application       | —                | —        | ✓    | —         |
| Clear User sessions            | ✓                | —        | ✓    | —         |

> **Note** — actions are available from the request side panel, in workflows, and in IT Agent playbooks. Sensitive actions can be gated behind approvals (see Branching & approvals).

### How the sync works

* **Initial import** — all users, groups, and app assignments are imported the first time you connect.
* **Continuous sync** — Siit refreshes the directory automatically (typically every few hours).
* **Real-time actions** — actions triggered from Siit (provision, revoke, reset, etc.) execute immediately and are reflected in the IdP.
* **Source of truth rules** — for each People field, pick which system wins if you're also connected to an HRIS. Configure this in **Settings → People → Fields**.

### HRIS + IdP: the best combination

Most customers connect **both** an HRIS and an IdP. Here's how they complement each other:

|                  | IdP                                       | HRIS                                            |
| ---------------- | ----------------------------------------- | ----------------------------------------------- |
| Source for       | Accounts, app access, authentication      | Employment data, org structure, lifecycle dates |
| Triggers in Siit | User created, group membership change     | Start / end dates, probation, anniversaries     |
| Typical actions  | Provisioning, SSO, group / app assignment | Pre-boarding sequences before accounts exist    |

Connecting both means a full **Day-1 onboarding workflow** can fire on the HRIS start date, then use the IdP to create the account and assign the right apps and groups — and a matching **offboarding** flow can cleanly revoke everything on the HRIS end date.

### Common use cases

* **Day-1 provisioning** — Trigger: HRIS Start date. Actions: IdP create user → add to baseline groups → assign app bundle by department.
* **Self-service access request** — Service: "Request access to app". Actions: manager approval → IdP Add application to user → notify requester.
* **Group membership request** — Trigger: Request submitted (App access form). Actions: approval → IdP Add to group → confirmation DM.
* **Password / MFA reset** — Service: "Reset my password" or "Reset MFA". Action: verify identity → IdP reset — gated by approval where required.
* **Offboarding on end date** — Trigger: HRIS End date. Actions: IdP revoke sessions → remove app access → suspend account → equipment pickup request.
* **Side-panel one-click actions** — From any request, agents can run IdP actions directly on the requester without leaving Siit.

### SSO is separate

This section covers IdP as a **directory and action source** (people sync + provisioning). If you're only looking to let users sign in to Siit with Google, Microsoft, Okta, or JumpCloud, see SAML - SSO.

Most customers do both: connect the IdP here to unlock actions, and enable SSO in Settings → Security → SSO for authentication.

### Getting started

1. Go to **Settings → Integrations** and pick your IdP in the library.
2. Authorize the connection (each IdP has its own flow — see the per-platform guides).
3. Review imported users, groups, and apps. Adjust mapping in **Settings → People → Fields** if needed.
4. Set the source of truth per field if you're also connected to an HRIS.
5. Try your first action from a request side panel, or build a workflow in **Workflows → New**.

Pick your IdP above to see the exact setup steps.