Access requests
Let someone ask for access to an app or a use case, and approve it in one click
Overview
An access request turns a dead end into a workflow. When a surface is marked as requestable and someone without access opens it, they are offered a request instead of being refused.
An approver allows or denies it. An approval takes effect immediately, at the next decision, with no cache to wait for.
Access requests apply to apps and app resources: a whole app surface such as Studio, Hub or a custom app, or one specific use case or tool inside an app.
They do not apply to ordinary actions. You cannot request kb.view. That belongs to the role and group model, which is a deliberate split: see two layers, not one.
Apps and entitlements
An app is any surface people open: Studio, Hub, the Admin Portal, or a custom app your organization registers. Each app can contain app resources, which are the use cases and tools reachable inside it.
Access to an app is decided by entitlements, which are sparse rules rather than a complete list.
| Effect | Meaning |
|---|---|
| Allow | This subject may open this target |
| Deny | This subject may not, and this beats any allow |
| Require approval | Neither allows nor forbids. It marks the target as requestable. |
An entitlement targets a subject, which is one of three things:
- One person
- Everyone in an organization
- A group
Absence of a rule means allowed. An app with Assignment required turned off is open to everyone in scope.
That default exists so nothing broke when this shipped. Turn Assignment required on for an app before you rely on entitlements to restrict it, otherwise the rules you add are narrowing something that was never closed.
The require_approval effect
This is the effect that makes requests possible, and its behaviour is worth stating precisely: it neither grants nor refuses.
On its own, require_approval means "a person who lacks access here may ask for it". It is what turns a hard denial into a request form. The approver's later allow is what actually grants access.
How a request flows
Someone opens a surface they cannot access
If the target carries require_approval for them, they see a request form rather than a refusal. They can add a reason, up to 1,000 characters.
The request is created as pending
Only one pending request per person per target is allowed. A second attempt does not create a duplicate.
Approvers are notified
Organization owners and admins are notified for an organization app. Platform superadmins are notified for a platform app.
Notifications are best effort and never block the request. If no approver notification arrives, the request still exists and is still visible on the Access Control page.
An approver decides
Approve mints an allow override for that person on that target, and marks the request approved. Deny marks it denied and grants nothing.
The requester is notified, and access works immediately
Because access is derived from rules plus overrides, the new allow takes effect at the next decision.
Who approves what
| Target | Approvers |
|---|---|
| An organization app, or a resource inside one | Organization owners and admins |
| A platform app, including the Admin Portal | Platform superadmins |
A request is reviewed on the Access Control page in the Admin Portal.
Setting it up
Turn on Assignment required for the app
Until you do, the app is open to everyone in scope, so entitlements have nothing to narrow.
Grant access to the populations that should already have it
Add allow entitlements for the groups and organizations that need the app day to day. Do this before the next step, so you are not generating requests from people who should never have needed to ask.
Add require_approval for the population that may ask
Scope it to the subject that should see the request form. Everyone in the organization is the usual choice for an internal app.
Test it with an account that has no access
Confirm the request form appears, the approval arrives, and access works afterwards.
Good practice
Otherwise every normal user's first action is to file a request, and the signal is lost in the noise.
Marking one use case requestable is a much smaller decision for an approver than marking a whole app.
If you approve the same request five times, the population is real. Put those people in a group and grant the group.
It is not a role and not a group membership, so it will not appear where you look for roles. Read effective permissions to see it.
Denying a request just marks the request denied. A deny entitlement is a standing rule that beats every allow. They are different things, and the second is much stronger.
Troubleshooting
Cause: The target carries no require_approval for them. Without it there is nothing to request, so the denial is final.
Fix: Add a require_approval entitlement for the subject that should be able to ask.
Cause: Notifications are best effort and are deliberately swallowed on failure, so that a notification problem can never block a request or a decision. It is also possible the organization has no owner or admin to notify.
Fix: Review pending requests on the Access Control page. They are there regardless of notification delivery.
Cause: Only one pending request per person per target is allowed, by design.
Fix: Decide the existing one.
Causes to check:
- A deny entitlement exists for that person, group or organization. Deny beats the approval's allow.
- The failure is a different action entirely. An approval grants the app surface, not the permissions needed inside it.
Cause: Assignment required is off, so the app is open to everyone in scope and your entitlements are narrowing nothing.
Fix: Turn it on.