Set up App Access Policies

Set up App Access Policies

App Access Policies let you control who can request access to which app, which role within that app, what information the request form collects, and how Siit grants the access.

Every workspace ships with safe defaults: an App owner approval policy and a Default role on every app. This guide walks you through adapting those defaults and rolling the feature out across your stack.

• Pro plan.
• At least one IdP connected (Okta, Microsoft Entra ID, Google Workspace, or JumpCloud) if you plan to use automatic provisioning. Manual provisioning works without an IdP.
• Apps imported into your Siit inventory. See Managing your app inventory.
• An admin role with the Manage policies and Define access rules permissions. See How to manage your Roles and Permissions.

Edit the default Approval Policy

Go to Settings → Approval Policies → App owner approval. Update the approval cycle to match how your company should sign off on app access requests by default.

Common patterns: manager approval first then app owner, or app owner only with a security review for sensitive apps.

Save. The change applies immediately to every Role still using this policy — which at this stage is every Role.

2 - Review the app owner on every application

Both the default Approval Policy and the Default role rely on the app owner. If an app has no owner, requests will stall at approval or provisioning.

Open the Applications view, sort by Owner, and fill in any blank fields. Apps without a clear owner can route to a fallback (a shared IT alias or named admin) — but the field must not be left empty.

3 - Enable the access request question on a test service

Pick an existing service that handles app access requests (or create a new one restricted to your own user). Go to Service Catalog → [service] → Form and add the Application question. Inside the question settings, toggle on Ask for a Role.

Save. Submitting that service in Slack, Microsoft Teams, or the portal will now ask the requester to pick an app and a Role, then route the request through the Role's Approval Policy and provisioning action.

4 - Add the access request question to your real services

Once the test passes, repeat step 3 for every customer-facing service that handles app access requests. From this point, all requests flow through App Access Policies using the Default role on each app and your edited Approval Policy — no further per-app work needed yet.

5 - Define Approval Policies and Roles for your top apps

Open the Application reporting dashboard to identify the apps with the highest request volume. For each top app, design the access flow before making changes:

1. Decide if the default Approval Policy fits, or if the app needs a custom one (e.g. finance approval for paid SaaS, security review for sensitive tooling). If needed, create it first in Settings → Approval Policies → New policy.
2. Open the app, go to the Roles tab, and create the Roles employees actually request (Editor, Admin, Viewer, or role-by-team segments).

For each Role, configure:

• Name — typically the role inside the app (e.g. Editor, Admin, Read-only).
• Audience — who can request this Role. Defaults to everyone; restrict by group when needed.
• Approval Policy — select from the workspace list.
• Form questions — toggle on Duration and Business reason when required. An empty form is fine when not needed.
• Provisioning action — choose one of the following:

• Manual app owner action — the app owner receives a task to grant access in the external system. Siit tracks the task on the request timeline.
• Add to group — select the IdP group that grants the Role. Siit calls the IdP to add the user once approvers sign off.
• Add to app instance — select the configured app instance to add the user directly. Available only on instances that expose a native add action.
• Mixed (add to group + manual action) — combine an IdP group for what the IdP can grant, plus a manual task for what it cannot. Useful when the IdP covers role membership but a separate seat assignment still needs a human.

Save. The new Role appears in the access request flow. The Default role remains available unless you delete it.

6 - Create additional Approval Policies as needed

As more apps come online with different governance needs, create new Approval Policies in Settings → Approval Policies → New policy and assign them to the relevant Roles. Reuse the same policy across every Role that shares the same governance requirements.

7 - Roll out to your remaining apps

For every app outside the top group, repeat step 5: create the Roles that match real access patterns, assign the right Approval Policy, and pick the provisioning method.

Run each app on manual provisioning for a week or two before switching to add-to-group, so the audience and IdP mapping are stable before automation takes over. The best-practice guide covers the recommended pacing in detail.

Verify your setup

Submit a test access request through one of your services. Pick an app and Role you configured, then confirm:

• The Approval Policy fires the right approvers in the right order.
• The form asks for the questions you toggled on (Duration, Business reason), and skips them otherwise.
• The provisioning action runs correctly: manual task for manual Roles, IdP group change for add-to-group Roles, instance assignment for add-to-instance Roles.
• The App Access appears in the app's activity feed with the full timeline, and in the Request list when filtered by App Access.

What to do next

• Read the App Access Policies FAQ for common questions on Roles, audiences, expirations, and IdP behavior.
• See Roll out App Access Policies across your stack for recommended phasing, tips, and metrics.
• If a request misbehaves, see Troubleshoot App Access Policies.