Skip to main content
Approval policies determine who must approve a user’s access request, and in what order (e.g., first a manager, then the business owner). Use this guide to configure simple or multi-step approvals based on your organization’s needs.

​
Creating a Policy

  • Manager: The request goes to the requester’s manager for approval.
  • Application Admins: The request goes directly to the assigned application admins responsible for that app.
  • Business Owner: The request goes to the owner of the requested app.
  • Individual User: The request goes to a specific user. Only users who are in your Slack workspace can be picked, because approval requests are delivered as Slack messages.

​
Assigning the Policy to Apps

Go to Settings → Policies, open the policy you want to use, and assign the apps that should follow it. If no dedicated policy is chosen for an app, the Default policy applies.
Match a policy on a permission type instead of appsYou don’t have to pick apps one by one. Leave the app list empty and assign the policy to an entitlement type (e.g., elevated permissions). The policy will then run whenever a permission of that type is requested, regardless of which app.

​
Handling Out-of-Office Approvers

  • If an approver is unavailable, an AccessOwl Org Admin can override approvals on their behalf by opening the access request in the admin interface.
  • The system audit log will show who performed the override and which user it was done on behalf of.

​
When an Approver is Offboarded

Approval steps point at a role (such as Business Owner or Application Admins), not at a specific person. If the person holding that role is offboarded, the step does not break and the request never falls back to the offboarded person’s manager. Instead, the role itself is reassigned - see Handling Role Changes for how AccessOwl reassigns the Business Owner and Application Admin roles. Requests that were already in flight keep the approvers they were created with. An AccessOwl Org Admin can approve those requests on the offboarded person’s behalf from the admin interface, and the audit log records who acted and on whose behalf.

​
Best Practices

Keep It Simple

Avoid adding more approval steps than you need. Manager + App Admin are often enough for critical apps.

Use Auto-Approve for Low-Risk Apps

This cuts down on notification noise and speeds up onboarding for common tools.

​
FAQ

They can be a user, but not an approver.Anyone can exist in AccessOwl without a Slack account. You can create them by onboarding them under Users, or by typing their full email address into an access request, which is the usual route for contractors and consultants outside your domain. See Onboarding Contractors and External Users. Their access is provisioned, tracked and reviewed like any other user’s.Approvals work differently. AccessOwl delivers approval requests as Slack messages, so a person who is not in your Slack workspace never receives one. They cannot be picked as an Individual User approver, and they cannot carry an approval step as Manager, Business Owner or Application Admin either. Point those roles at someone who is in your Slack workspace, or have an Org Admin approve on their behalf from the admin interface.The same applies to AccessOwl roles such as Org Admin, HR User and View-only. The role picker in Settings only lists people who exist in your connected Slack workspace.
Currently, AccessOwl does not offer an automatic expiration feature for approved requests. You can manually revoke or schedule an offboarding event once you no longer need that access.
Right now, no. You must manually override or reassign approvals. The product roadmap includes potential escalation features in future releases.
By default, policies apply at the application level. If you need more granular assignment by role or department, consider using separate apps or blocks and attaching distinct policies to each. More advanced user-based policy assignments are under consideration.
There is no “select all apps” option. Approval policies match on two different dimensions:
  • App-level policies apply to standard access requests for a specific application (e.g., “Critical Applications” policy assigned to Slack).
  • Entitlement-level policies apply to requests for a specific permission type (e.g., “Elevated Access” policy assigned to elevated permissions), regardless of which app. These policies do not need any apps assigned to them.
To make a policy run across all apps for a given entitlement, leave the app list empty and assign the policy to that entitlement type. App-level and entitlement-level policies can coexist: a standard access request triggers the app-level policy, while a request for an elevated permission triggers the entitlement-level policy unless the app already has its own app-level policy (see precedence below).
The app-level policy wins. App-specific policies always take precedence over entitlement-level policies. The entitlement-level policy only applies to apps that don’t have their own app-level policy assigned.
No. An AccessOwl Org Admin always has the option to override in emergencies.
No. Each app can only be assigned to a single approval policy. If no dedicated policy is chosen, the Default Policy applies automatically. This means there is no conflict between two app-level policies targeting the same app.
The approvers on a request are locked in when the request is created. If the Business Owner or the policy changes afterwards, existing in-flight requests keep the approvers they were created with. Only new requests use the updated approval chain.
Last modified on August 20, 2026