> 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/guides/data-management/app-policy-best-practices.md).

# App access policy best practices

Roll out App Access Policies app by app: adapt the default Approval Policy and Default role, add automatic provisioning in priority order, and track metrics while avoiding common pitfalls

{% hint style="success" %}
**Note:** App Access Policies are available on the **Pro plan**.
{% endhint %}

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 provisionin**g: 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.siit.io/guides/data-management/app-policy-best-practices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.