Roll out App Access Policies across your stack without breaking existing access

App Access Policies work out of the box — every workspace ships with a default Approval Policy and every app ships with a Default role. The rollout below adapts those defaults, then layers automatic provisioning on top, app by app, in priority order. Most workspaces complete the full rollout in a quarter, but you get a working audit baseline within the first hour.

This playbook is for IT and People Ops teams with at least one IdP connected and 5 or more apps that already see manual or workflow-driven access requests. It works best in workspaces with 100+ employees, where request volume makes a per-app workflow approach feel heavy. Smaller workspaces can still use the feature, but the defaults often cover them without much custom work.

Three guiding principles

1. Set governance once, not per app. Workspace-wide Approval Policies and the per-app Default role mean a single change to the default policy applies everywhere.
2. Start with audit, then automate. Manual provisioning on every app gives you a clean audit log from day one. Add automatic provisioning where volume justifies the per-app work.
3. Migrate, don't rebuild. Existing workflow recipes keep running until you turn them off. Decommission them only after the App Access Policy version proves out on the same flow.

Step-by-step rollout plan

1. Match the default Approval Policy to your governance.Open Settings → Approval Policies → App owner approval and edit the approval cycle. Manager approval first, then app owner, is a common starting point. See Set up App Access Policies for the full walkthrough.
2. Sweep app owners across your inventory.The default policy approves via app owner — if the field is blank, requests stall. Open the Applications view, sort by Owner, and fill every blank. Apps with no clear owner can point to a shared IT alias.
3. Test the request flow on yourself.Create a new service restricted to your own user, add the Application question withAsk for a Roleon, and submit one end-to-end request. Confirm the approval cycle and manual provisioning task land as expected before going wider.
4. Roll the question out to your real services.Add the Application question withAsk for a Roleto every customer-facing service that handles app access requests. Every app now routes through App Access Policies using the Default role and your edited Approval Policy. You have your audit baseline — no per-app work needed yet.
5. Define Roles and Approval Policies for your top apps.Use the Application reporting dashboard to find your highest-volume apps. For each: decide if the default policy fits or if a custom one is needed, then open the app'sRolestab and create the Roles employees actually request (Editor, Admin, Viewer, role-by-team). Start with manual provisioning; switch toAdd to group,Add to app instance, or the mixed two-step once you trust the audience and IdP mapping.
6. Create additional Approval Policies as governance variation appears.When a sensitive app needs security approval or a paid app needs finance approval, create a new policy in Settings → Approval Policies → New policy and assign it to the relevant Roles. Reuse the same policy across every Role with the same sign-off chain.
7. Roll out to your remaining apps one by one.Repeat step 5 across the rest of your inventory. Once an app's Roles are in production and request volume has moved to the new flow, turn off the legacy workflow for that app. Keep the old recipe in an internal note as a fallback for one cycle, then delete.
8. Track, then refine.Watch the activity feed on each major app and the workspace-wide Request list filtered byApp Access. Each App Access carries its own state history independent of the Request lifecycle — the app's activity feed is the source of truth for who has what access even after requests close. Adjust audiences, durations, and provisioning methods based on what real requests look like.

Tips

• Pre-decide the form in your Roles.Define audiences by department, location, or seniority, then turn off Business reason and Duration when not needed. The form auto-completes what employees would otherwise type — fewer stalled requests, fewer back-and-forth messages.
• Combine with Triage Agent.Triage Agent routes the employee's Slack message to the right service, which picks up the Application question and runs the App Access flow automatically — no manual triage needed for anything that fits a configured Role.
• One Approval Policy per governance pattern, not per app.The default App owner approval covers most cases. Add Manager + App owner for sensitive apps and Finance + App owner for paid SaaS. Resist creating one policy per app.
• Run a couple of weeks on manual before automating.Manual provisioning for the first dozen real requests catches audience mismatches before they become silent automatic grants.
• Use the mixed two-step for partial IdP coverage.When the IdP can handle group membership but a separate seat assignment still needs a human, the mixed method keeps what can be automated automated, and routes the manual part to the right person.
• Audit monthly via the app activity feed.Spot-check recent App Access records on your high-volume apps. Confirm every transition is captured and deprovisioning tasks land when access expires.

What to measure

• Time from request to provisioningHow long an average App Access takes end to end. Visible in Siit Analytics by service or by app.
• Manual vs. automatic provisioning sharePercentage of App Access records granted via add-to-group or add-to-instance versus manual owner action. Drives prioritization of which apps to automate next.
• Approval cycle durationTime spent in approval steps. Surfaces over-engineered policies or stale approvers.
• Expirations honored on scheduleCount of App Access records that expire on or before their scheduled date. Confirms your deprovisioning task assignment is working.

Common pitfalls

• Too many Approval Policies.Every app feels unique at first — resist creating one policy per app. Start with one or two and add more only when a real governance need appears.
• Audience overlap on the same app.Two Roles with overlapping audiences and different provisioning actions confuse requesters. Use audience segmentation that maps cleanly to your IdP groups.
• Forgetting the legacy workflow.A workflow recipe and a Role can both fire on the same app, creating duplicate approvals or provisioning. Decommission the old workflow once the Role version is stable.
• Blank Owner field.Default policy routes to app owner; manual provisioning routes to app owner. A blank field stalls requests. Sweep the Applications view before going live and re-sweep monthly.
• Treating Duration as optional everywhere.Apps with sensitive data benefit from forced expiration. Turn the Duration question on for those Roles even when the rest of your Roles don't need it.