App access policies

App Access Policies are available on the Pro plan.

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.

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.

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: business reason and access duration only appear when the Role asks for them. Roles can ask for both, one, or neither.

• Sit through approval: the Role's Approval Policy fires the cycle and routes the request to the right approvers in the right order.

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

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.

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

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

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 state transition on every App Access for that app, in chronological order. The feed is the source of truth for who has access to what.

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

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 with a governance and provisioning layer on top. Automatic provisioning rides on the IdP integration covered in 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, and the per-Role permission scopes (Manage policies, Define access rules) extend the model in Roles and permissions.