Skip to main content

Requestable Roles

Make any application role self-service requestable — the SailPoint "business role" pattern. Users request a role from the User Portal, it runs through approval (or admin review), and on approval the role is granted automatically. Every step is logged and emailed.

Making a role requestable​

  1. Open Admin → Roles and edit (or create) an app role.
  2. Turn on Requestable. Optionally attach an approval chain and set a default request duration.
  3. Save. The role now appears in the portal's Request Access → Roles tab for eligible users.

Roles that are not marked requestable continue to be granted the usual ways — role policies, group mappings, or direct admin assignment — and never show up in the request catalog.

The request lifecycle​

  1. User opens Request Access → Roles (/portal/request-access), picks a role, adds an optional justification, and submits.
  2. System records the request, writes an audit entry, and emails the requester a confirmation. The request is always reviewed — it starts the attached approval chain, or waits for single-level admin review — and shows as Pending under My Requests.
  3. Approver / admin approves or denies it from Admin → Access Requests (role requests section).
  4. System grants the role on approval and emails the requester the outcome. Denied requests are emailed with the reviewer's note.

Segregation-of-Duties policies are enforced at grant time — a conflicting grant is blocked (PREVENT) or recorded as a violation (WARN). See Segregation of Duties.

Admin (nexusID) roles — time-boxed​

Application roles above grant access inside an app. You can also make admin (RBAC) roles — the roles that grant permissions in the nexusID admin console — requestable, but these are time-boxed: an approved request grants the role only for a chosen/default duration, then it expires automatically (the permission check stops honoring it — no manual clean-up needed).

  1. Open Admin → Roles and turn on Requestable for a role. This works for any role, including built-in system roles — the toggle controls requestability only, not the role's locked permissions.
  2. Users request it from the portal's Request Access → nexusID Roles tab.
  3. On approval the role is granted via the standard assignment path, which enforces a privilege-boundary guard: an approver can never grant a role beyond their own authority, and never Super Administrator.
SSO logins

Under Entra/Azure admin login, an approved admin role takes effect on the user's next sign-in (SSO sessions resolve their permissions at login) — the console honors locally-granted roles alongside the Entra App-Roles claim.

Licensing​

Requestable roles (app and admin) are part of Access Governance (Premium / Enterprise tiers, and the trial). On lower tiers the roles request catalog is empty.