Skip to content
  • There are no suggestions because the search field is empty.

App Access Policies Best Practices

Note: App Access Policies are available on the Pro plan.

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.

When this approach fits

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.

💡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 provisioning: how long an average App Access takes end to end. Visible in Siit Analytics by service or by app.
    • Manual vs. automatic provisioning share: percentage 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 duration: time spent in approval steps. Surfaces over-engineered policies or stale approvers.
    • Expirations honored on schedule: count 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.