Access requests and resource owners
How an app, group, role or bundle request finds its approver, why a role request always needs a second sign-off, and what happens when nobody set an owner.
An identity-governance access request is how someone asks for an app, a group, an admin role, or an entitlement bundle, and how somebody else decides. It lives under Identity governance, at /iam/governance/access-requests, and it is unrelated to the privileged-access module's own request-and-approval workflow for checking out a credential.
What you can request
| Resource type | What approval grants | Approval steps |
|---|---|---|
app | Sign-in access to one application (the same assignment App assignments tracks). | One |
group | Membership in one group. | One |
role | The requester's org role is set to this role. | Two — always |
bundle | Every entitlement, group and app item inside a requestable bundle, granted together. See Entitlements and bundles. | One |
An app request must also carry resource_label — the app's display name — because unlike a group or role id, an app id is an operator-authored slug with nothing else to resolve it to a readable name. Every request needs a reason of 1 to 2000 characters; leaving it blank is refused. An app or group request may optionally be time-bound with requested_days (1 to 3650): a role or bundle request cannot be, and naming a duration on one is refused outright — a role grant made through this path has no expiry, and neither does a bundle's.
How a request finds its approver
Every request resolves a first approval step when it is created, before anyone has seen it. The resolution order is fixed:
- For an app or group request, the resource's owner — see resource owners below — if one is set and is not the requester themselves.
- Otherwise, an organisation admin. The platform picks an admin other than the requester when more than one exists, and falls back to the requester themselves only if they are the sole admin in the org — the same reasoning a small tenant's very first request has to work under.
Resource owners
A resource owner is one person named against one app or group — at /iam/governance/resource-owners — who becomes that resource's approval target under the chain above. Set one from the console's Set an owner dialog, or PUT /organizations/{orgID}/governance/resource-owners with resource_type (app or group), resource_id, and owner_user_id. Setting an owner twice for the same resource replaces the previous one rather than erroring.
The same owner lookup also backs an access-review reviewer hook, so setting an owner here can also change who is asked to certify that resource's members in a periodic access review — see Access reviews and certification for that side of it.
Deciding a request
The screen shows three views, all backed by the same list endpoint: Pending for me (an unresolved step names you as approver), Mine (requests you raised), and All, which only an administrator can see — anyone else gets a plain notice explaining why, not an empty table pretending nothing is pending.
To act on a step you must either be the exact user named as its approver, or hold iam:governance.write as an administrator override. Approving is POST /organizations/{orgID}/governance/requests/{id}/decide with {"approve": true, "note": "..."}; denying sends approve: false. A note is optional on either action. Only a pending request can be decided at all, and only its current step's named approver (or an admin) can decide it — there is no way to skip ahead or decide a future step early.
Denying a request at any step ends it immediately, marked rejected. Approving a non-final step simply advances current_step and notifies the next approver; nothing is granted until the last step is approved.
Separation of duties runs before the grant, not after
Approving the terminal step is where a separation-of-duties conflict set — see Separation of duties — gets its say. For a role or group request, the platform checks whether granting it, on top of what the requester already holds, would put two members of an active block-mode conflict set in one person's hands. A blocked request never reaches the grant call: it is marked rejected with the conflict's own message as the decision note, and the requester is notified that the request was blocked by a separation-of-duties rule, not simply denied by a person.
Cancelling a request you no longer need
POST /organizations/{orgID}/governance/requests/{id}/cancel works only on a pending request, and only for the requester themselves or an administrator. A decided request — approved, rejected, or already cancelled — cannot be cancelled again.
Who needs what permission
| Action | Permission required |
|---|---|
| Create a request, list your own or the ones pending for you, cancel your own | None beyond being an authenticated member of the org |
| List every request in the org (the All view) | iam:governance.write (used here as the admin check) |
| Decide a step that names you as approver | None extra — being the named approver is enough |
| Decide any step as an administrator override | iam:governance.write |
| Manage resource owners | iam:governance.read to view, iam:governance.write to set or remove |
What is recorded: iam.governance.access_request_created, iam.governance.access_request_approved, iam.governance.access_request_rejected, and iam.governance.owner_set, each carrying the resource type and id. A separation-of-duties block on the terminal step is recorded separately, under iam.governance.sod_blocked — see Separation of duties for what that entry and its flag-mode counterpart hold.
What to do next
- Set an owner on any app or group whose requests should not default to your admins.
- Read Entitlements and bundles before building a requestable bundle, so you know exactly what applying one does and does not do.
- Define a conflict set for any role or group combination that must never be held together.
- Building a role that grants exactly enough — before you let a role become requestable through this flow.