Every access has a reason.

1. User
2. IGA
3. Manager
4. App

1. request: Payment approver

   Step 1 of 8

   Ada asks for a role from the catalog

   In plain words Like ordering from a menu: the items have names people understand, and you add a short reason.

   Instead of a free-text ticket, the user picks a business role from a catalog. Behind the friendly name sit the technical entitlements: groups, ERP roles, permissions.

   POST /requests
   {
     "requestedFor": "ada.lovelace",
     "item": "ERP · Payment approver",
     "justification": "Covering for the AP lead in Q4",
     "endDate": "2026-12-31"
   }

2. approve? SoD ✓

   Step 2 of 8

   Policy check, then routing

   In plain words Before anyone says yes, the system checks a rule: the same person must not both create a supplier and pay it.

   IGA evaluates segregation of duties (SoD) rules against what Ada already has. No conflict, so the request goes to her manager. A conflict would block it or require a documented exception.

   rule  SOD-AP-01  "Create vendor" ✕ "Approve payment"
   ada.lovelace has: ERP · Invoice viewer
   result: no conflict ✓  → route to manager

3. approved

   Step 3 of 8

   The manager approves

   In plain words The manager signs off, and the signature is kept for the auditors.

   Who approved, when and why is stored with the request. Sensitive roles often add a second approver, the role or application owner.

4. provision role

   Step 4 of 8

   Provisioning to the app

   In plain words The system does the change itself, so nobody has to remember to do it by hand.

   A connector, SCIM or an API call adds the role in the target system. Apps without a connector get a ticket for a human, which is slower and needs checking.

   PATCH /scim/v2/Users/2819c223
   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
     "Operations": [{
       "op": "add",
       "path": "roles",
       "value": [{ "value": "PAYMENT_APPROVER" }]
     }]
   }

5. aggregate accounts

   Step 5 of 8

   Reconciliation

   In plain words Every night the system counts who is really inside and compares it with the list of who should be.

   IGA reads back accounts and roles from the app. Anything granted directly in the app, outside IGA, shows up as a difference to fix or justify.

   ERP · Payment approver
     ada.lovelace   ✓ requested and approved
     mrossi         ✕ not found in IGA  → flagged

6. review: keep or revoke?

   Step 6 of 8

   The quarterly access review

   In plain words Every few months the manager gets a list: "do these people still need this?".

   A certification campaign asks owners to confirm each access. The risk is rubber-stamping: good campaigns show context, such as last use and peer comparison, and focus on risky access.

7. revoke

   Step 7 of 8

   Ada no longer needs it

   In plain words The cover period is over, so the manager says no.

   The decision is recorded with the campaign. Access with an end date would also expire on its own, without waiting for the review.

8. remove role

   Step 8 of 8

   Deprovisioning closes the loop

   In plain words The badge is switched off, and there is a record of who asked, who approved and who took it back.

   IGA removes the role and the next reconciliation confirms it is gone. Request, approval, review and removal together are the evidence auditors ask for.

Flow complete.