Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.accessowl.com/llms.txt

Use this file to discover all available pages before exploring further.

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.

​
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.

​
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

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.