> 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/data-management/app-access-policies.md). # App access policies {% hint style="info" %} App Access Policies are available on the Pro plan. {% endhint %} App Access Policies are how Siit governs access to your apps end to end: who can ask, what they have to provide, who signs off, and how the access actually lands in the target system. Every workspace and every app start with safe defaults so the feature works on day one, then earns its keep as you configure Roles per app.
### Why App Access Policies matter * **Central governance**: define an approval cycle once and reuse it across every app, instead of recreating the same `Manager + App owner` chain in 30 different workflows. * **Right-sized requests**: ask for a business reason or an access duration only where it matters, and skip them everywhere else. Less friction for employees, cleaner audit for sensitive apps. * **Multiple provisioning paths**: manual app owner action, automatic add-to-group on the connected IdP, direct add-to-app-instance, or a mixed two-step that combines a group call with a follow-up manual task. * **Day-one defaults**: every workspace ships with an `App owner approval` policy and every app ships with a `Default role`, so any new app accepts access requests as soon as it lands in your inventory. * **Built-in audit**: every App Access record carries its own state machine, visible at any time on the application activity feed, even after the parent Request closes. The feed reads as an event log of only the events that moved the status: request creation, every approval, manual and automatic provisioning, provisioning failures, cancellations, expirations, and planned deprovisioning. ### Common use cases * **Self-service Figma access for the marketing team.** Twelve hires join over a month. The marketing-segmented Role on Figma adds each new starter to the `Marketing` group in Okta automatically as soon as Manager and App owner sign off. No IT touch. * **Time-bounded contractor access.** A freelancer needs the CMS for 30 days. The Role asks for a duration, the App Access record gets a 30-day expiration, and Siit creates the deprovisioning task on the morning it expires. * **Sensitive-app approvals.** Salesforce admin access goes through Finance, Security, then App owner. One `Sensitive admin access` Approval Policy carries the chain, and every Admin Role on Salesforce, Workday, and your HR systems reuses it. * **Partial-SCIM apps.** Your IdP can put a user in the right Notion group, but the editor seat assignment still needs a click in Notion. The mixed two-step provisioning runs the group call automatically and pings the app owner for the seat. * **Multi-instance apps without confusion.** Zoom EU and Zoom US share a brand but live as separate instances. The Role for the EU team adds users to the EU instance and the Role for the US team adds users to the US instance. The requester never sees the routing. * **Quarterly access reviews.** Access records expire on schedule and create deprovisioning tasks, so quarterly reviews start from a clean list instead of a sprawling "who has what" spreadsheet. * **Bulk Role creation from an existing IdP.** Your Okta tenant already has 40 groups mapped to apps. The IdP setup flow lets you pick the groups you need and Siit creates matching Roles in one action, no manual Role creation per group. * **Frictionless default apps.** Everyone gets Slack and the internal wiki on day one. Their Default role is set to `Skip approval`, so Siit provisions access the moment the request comes in, no approval round for an app nobody would ever reject. ### How an access request flows A request follows the same shape end to end whether it comes from Slack, Microsoft Teams, or the portal. The employee picks the app, the Role configuration takes over, and the access lands once approvers sign off. * **Pick the app(s)**: the employee selects one or more applications inside any service form. One request can cover several apps in one go. * **Pick a Role (or auto-route)**: if the app has Roles configured, the employee picks from the list. If only one Role applies, the request routes automatically. Apps without custom Roles use the Default role and ping the app owner manually. * **Answer the Role's form questions, one step per app**: business reason and access duration only appear when the Role asks for them, and each selected application now gets its own step inside the same modal, in sequence. A step with a single available Role and no duration or business reason to collect is skipped automatically. * **Sit through approval**: the Role's Approval Policy fires the cycle and routes the request to the right approvers in the right order, unless the Role is set to `Skip approval`. In that case Siit skips this step entirely and provisions the access right away. * **Get provisioned**: once approvers sign off, Siit provisions the access. Manual app owner task, add-to-group on the connected IdP, add-to-app-instance, or the mixed two-step, depending on the Role. > **Notes** - When a Role is set to `Skip approval`, the App Access card doesn't show an approval cycle section, since none ran. The card only reflects what actually happened.\ > \- On the portal, this step-per-app flow now runs inline: after submitting the request, the employee stays in the same modal instead of receiving a second form afterward. Slack has behaved this way already; the portal now matches it.
### What you control as an admin The configuration sits in two surfaces: workspace-level Approval Policies that define how requests get signed off, and per-app Roles that bind a policy to an audience, a form shape, and a provisioning action. * **Approval Policies**: reusable approval cycles defined once in `Settings → Approval Policies` and reused across many Roles. The default `App owner approval` policy ships ready to use; edit it once and every Default role inherits the change. * **Skip approval**: a fourth option on the Role's approval step, alongside an Approval Policy, auto-accept, and auto-reject. Pick it for the apps everyone gets by default, where an approval round would only add a step, not a decision. Siit moves straight to provisioning: no approver is notified and no approval round opens. * **Roles per app**: each app carries a `Roles` tab where you bind audience, Approval Policy, form questions, and provisioning action together. One app can carry as many Roles as the access pattern needs (`Editor`, `Admin`, `Read-only`, role-by-team, role-by-region). * When an IdP is connected, you can also create Roles in bulk by importing groups directly from Okta, JumpCloud, Microsoft Entra ID, or Google Workspace. Siit lists every group linked to the app, flags any group already used in another Role, and creates all selected Roles in a single action. * **Form questions on the Role**: business reason and duration toggle independently per Role. Duration accepts a free-form value or a fixed cap. * **Provisioning per Role**: pick manual app owner action for full human control, add-to-group for hands-off IdP provisioning, add-to-app-instance when the integration exposes a direct action, or the mixed two-step when the IdP handles part of the access and a human handles the rest. * **Permission scopes**: `Manage policies` controls workspace-level governance; `Define access rules` controls per-app Roles. Separate the two so App owners can build their own Roles without touching the policy library. #### Sequential approval rounds An Approval Policy can chain more than one round of approval. Add as many rounds as the policy needs, for example manager first, then security, then finance, and Siit walks through them one at a time. * **Order matters.** Round 2 only starts once every approver in Round 1 has signed off. * **A rejection stops the chain.** If any round is rejected, every round still waiting behind it is cancelled automatically. No approver downstream ever sees a request that already failed upstream. * **Provisioning waits for the last signature.** App Access provisioning fires only once every round in the policy is approved, so nothing gets granted partway through the chain. Configure rounds from `Settings → Approval Policies → [Policy] → Add round`. Use rounds when a single approval step is not enough for the risk level of an app. A policy for admin level access might need the App owner, then Security, then Finance, each involved only once the previous group has cleared it.
#### **Reviewing past approval rounds** The App Access card shows the round currently in progress by default. Step back through any round that already closed with the arrows next to the round counter to see who approved and when, without leaving the card or opening the activity feed. Rounds that have not started yet stay out of the card until it is their turn.
### Where App Access lives Each granted access becomes an App Access record with its own lifecycle, independent of the Request that produced it. The record outlives the Request and stays auditable in two places. * **Application activity feed**: every event that changed an App Access status for that app, in chronological order, from request creation through approvals, provisioning, failures, cancellations, expirations, and planned deprovisioning. App Access records that predate this event log were backfilled, so older history reads the same way as new. The feed is the source of truth for who has access to what, and why. * **App Access filter on the Request list**: surfaces every Request currently carrying at least one App Access record, helpful for triaging requests still in flight. * **Independent lifecycle**: closing the parent Request after provisioning runs does not interrupt the App Access. Scheduled deprovisioning still fires when the date arrives. * **One Request, many App Accesses**: an employee can ask for access to several apps in a single Request. Each app produces its own App Access record with its own state machine. * **Active Users tab**: the app's live roster, reconciled in real time from every source IdP, App Access, and direct adds with each person's access origin shown, so admins can tell why someone has access before revoking it.
### Transparent to your requesters From the requester side, it's a normal access request. They pick the app, optionally a Role, answer the questions the Role asks (often none), and wait. The governance chain, the multi-instance routing, the provisioning method, the audit trail: all admin-side. The requester just gets the access. ### Where App Access Policies fit App Access Policies extend the inventory in [Apps](https://docs.siit.io/data-management/apps) with a governance and provisioning layer on top. Automatic provisioning rides on the IdP integration covered in [IAM](https://docs.siit.io/integrations/iam), with add-to-group calling the connected Identity Provider directly. The approval cycle inside every Approval Policy reuses the mechanics from [Branching and approvals](https://docs.siit.io/workflow/branching-and-approvals), and the per-Role permission scopes (`Manage policies`, `Define access rules`) extend the model in [Roles and permissions](https://docs.siit.io/workspace/roles-and-permissions). ### Canceling or following up on a pending approval The manual actions you already use on standard approvals now extend to App Access approvals too. * **Cancel app access approval**: mark a pending app access approval as expired. A confirmation step prevents accidental cancellations. * **Send reminder**: nudge the pending approver with a one‑click reminder. Siit logs the reminder as an event on the request timeline. Open any request with a pending app access approval and click the **⋯** menu next to the **Waiting approval** status to trigger either action.
> **Note** : Both actions are available to any admin who can access the request, and every cancellation or reminder is recorded so the audit trail stays complete even when a request needed a manual push.