Roles and role mining
Anyone who has lived through a role-engineering project knows the shape of it: months of workshops, a role catalogue nobody recognises, and an estate that carried on granting access directly the entire time. This page is the model behind the alternative, and its limits. The short version: the platform reads the access people already hold, proposes candidate roles with the evidence attached, and then makes a named human owner and a reviewer chain the only route by which any of it becomes real.
What a proposal is
A run reads every grant the platform has correlated to an identity and applies eight grouping strategies, each a separate named rule: an identity-type baseline (all employees, all contractors), internal versus external, organisational unit, context membership, job function, context hierarchy (an org unit with or without its subtree), permission clustering (start from a permission, find the cohort that dominates its holders), and a two-attribute combination such as department × location. Two further detectors look at roles you already have: one proposes extending a role whose members have all quietly acquired the same extra permission, the other (Automate) finds people who already hold nearly everything an existing role contains without holding the role, and proposes one access policy for that role under a condition that describes them, rather than a new role or a batch of requests. Accepting an Automate proposal requires you to acknowledge the number of newcomers the condition would also match, and the policy still goes through the role type's approval chain before it is on. Extension and Automate proposals are accepted one at a time, never in bulk.
An Extend proposal says how its members hold what it proposes today: through a policy, through another role, through an approved request, with no recorded reason, or not at all. A proposal that adds no new access and makes nothing governed that was not is labelled Clean-up and sorts last. A role has at most one open Extend proposal; a newer one replaces the older, and the list folds proposals that extend the same role under one line.
Changing a live role needs its owner's approval. Accepting an Extend proposal, adding or removing a child on an active role (or reverting one) and attaching a newly onboarded entitlement to an active business role do not change the role at once. They send the change to the role's owner, or to the IAM team when the role has no owner; a change that would break a separation-of-duties rule also goes to the security team. The role stays as it is until every approver has said yes, one "no" rejects the change, and a role-mining decider can withdraw it while it waits. The inbox task shows the role, who asked, what would change and any rule it would break. This is on by default; an administrator can switch it off under Governance settings, Business defaults, and then these changes apply at once as before. Draft roles change at once either way. Adding a child with a higher risk level raises the role's risk level; removing one never lowers it.
The strategies are deliberately separate and deliberately dull. There is no model that
learns; there is no cluster identifier. An auditor asking "why is this a role?" gets one
sentence back — this cohort is department = Finance and identity_type = employee, found
by the organisational-unit rule — and that sentence is the whole derivation.
Each proposal carries per-entitlement evidence rather than a verdict:
- How many of the cohort hold it (and how many do not), and how many people outside the cohort hold it.
- Coverage — the share of the cohort holding it. Exclusivity — the share of the entitlement's holders who are in the cohort (holders in the cohort divided by all holders), the two counts printed on the row.
- A recommendation: include at coverage ≥ 70% and exclusivity ≥ 50%, consider between 50% and 70%, skip below. These thresholds, the minimum cohort size (3), the confidence cut-off and the threshold for extension proposals are tenant settings in Governance settings. A row whose exclusivity is under 20% is always skipped and is labelled with the wider group that explains it ("Belongs to Belgium") or "Held widely outside this group". A draft with nothing left to include is not offered as a proposal. Only the include entries are ticked by default; the rest stay visible so you can see what was nearly a role.
- Outliers — people outside the cohort who hold the proposed access — and missing grants, cohort members who lack it. Both are listed. Neither is acted on.
A confidence figure sits on top, weighted half on average coverage, three-tenths on average exclusivity and two-tenths on cohort size, capped at twenty members. It is a formula, printed as a formula. It ranks proposals against each other; it does not claim a probability that the role is correct.
That is what "framed as an opportunity" means concretely. A run does not produce the role model to be accepted or rejected as a whole. It produces independent candidates, each defensible on its own evidence, and you take the ones that hold. The rest cost nothing to leave.
One exclusion is worth stating because its absence caused a real defect: already- formalised roles never re-enter the candidate pool. Role membership is projected into the access model as an ordinary grant, so without the exclusion the next run saw a formalised role as a permission held by 100% of its own members and nobody else — a perfect candidate — and proposed a role wrapping the role. The exclusion is by entitlement category, not by naming convention.
Coverage, before and after
Every run reports role-model coverage before and after. It is one definition, shared with the Access posture "via role model" figure, the Coverage tab and the proposals header, so they agree. Both numbers use one denominator: the grants of identity-linked accounts that exist in the target system. Orphan grants, empty rows, suspended or held grants, and grants still to be provisioned are left out of both sides.
Before is the share of those grants whose Expected-access source is a role or a policy. An approved request is governed but is not the role model, so it counts in the denominator only; mining is what moves it to a role. A grant with no source is access that exists in a target system for no recorded reason.
After is the union of two sets over that same denominator: the grants already covered, plus the grants a member would newly hold through a proposal's default include set. Because it is a union with the baseline, "after" can never be lower than "before" — accepting a proposal can only add explanation, never remove it.
This is stated so precisely because the first version was wrong in a way that read as a product defect rather than an arithmetic one. It counted only the newly explained grants and divided by a different denominator — distinct identity/entitlement pairs rather than grants — so a run could report coverage falling from 0.1% to 0%, which is not a bad result but an impossible one.
Coverage is a live measurement taken when the run happens. A later run on a tenant that has synced new, unexplained access can read lower without anything being wrong. A card's own coverage figure is local to its group and is labelled that way, and gains are shown in grants rather than percentage points. A stored proposal that names an entitlement which has since been removed is marked stale and should be re-run.
A card also says what the role holds and what it adds: how many entitlements are in the role and how many more the cohort holds that were not proposed, and how many of the grants it covers would be newly backed by a role or policy. Confidence alone does not make a proposal a high-value opportunity: at least half of the grants it covers must be new to the role model. A confident proposal for access that is already governed is listed as Mostly already governed instead. The summary bar counts all pending proposals, whatever the filters show, because the bulk-accept button beside it acts on all of them.
What the figure does not promise: it projects the effect of accepting every proposal in the run at its default include set. Accept three of eleven and you get roughly three elevenths of the story. It is a projection over a hypothetical, not a forecast.
A role needs an owner before it can exist
Formalising a proposal without a role owner is refused by the server, not merely discouraged by the interface. Both routes are gated: the one-click formalisation on the mining page, and the path where a role is built in the role wizard and then linked back to the proposal. Either returns an unprocessable-entity error naming the missing owner.
The reasoning is not tidiness. A role with no owner has nobody to start its approval chain, nobody to answer for it at recertification, and nobody who notices when it outlives the project that asked for it. It will still be granting access in three years, and the first person to ask why will be an auditor. The gate exists because an unowned role is the exact artefact a role-engineering project leaves behind.
The owner is polymorphic: a person, an IGA group (a pool, so departures do not orphan the role), or a context owner — ownership by reference to an organisational unit, so turnover follows the org chart rather than requiring a handover. A business role type is required alongside it, because the type is what carries the governance defaults the role inherits.
This is also where "one click" is and is not honest. A role type may name a default owner group, and formalisation resolves it — genuinely one click. A role type whose default is an identity or a context carries no value to resolve, so it still requires a choice. Bulk formalisation above a confidence threshold runs the same gate per proposal and collects per-proposal errors rather than failing the batch: proposals whose role type names a group go through, the others come back named, and nothing is silently skipped.
The chain comes from the role type, not from the run
The reviewer chain for a formalisation resolves in one authoritative order, shared by every path that creates a role:
- An inline override set by the administrator on the formalisation screen.
- The role type's chain — either a named chain from the central registry, or the type's own inline chain.
- The tenant's registry default for role certification.
- A single-step manager fallback, so a path always exists.
Mining generates no chain of its own. It used to, and that is the point: a role's chain was defined in three unaligned places and the least visible one won. A "Baseline" role type configured to route to the role owner then the IAM team was overridden by a chain the mining algorithm had hard-coded to security, so the configuration an administrator could see was decoration. Proposals now leave the field empty and fall through to the type. The correction is forward-looking; proposals created before it still carry their old chain.
Where a chain came from is recorded on each spawned decision task, so oversight can answer "how was this routed?" without re-deriving it.
Formalisation therefore means submit for approval, not publish. The role is created in an in-approval stage and the access policy that assigns it is created disabled. Only when the chain completes does the role become active and the policy switch on. Steps scoped per entitlement fan out into one task per proposed permission, and a permission rejected at that step is removed from the role before it activates — so the thing that goes live is what the reviewers actually agreed to, not what was proposed.
Runs you start, and the run that runs itself
Alongside runs an administrator starts — optionally narrowed to one scope preset, or to a single connected system — a background sweep runs once a day by default (the interval is a tenant setting, and 0 switches it off) to keep the ungoverned-access analysis fresh, so that surface can show a real answer instead of a confident zero. Running that analysis again by hand is offered to an administrator and an auditor; other roles, the business admin included, see the last result without the button.
Because both write proposals, superseding is bucketed. The background sweep and user-facing runs form two separate buckets, and a run only supersedes pending proposals from its own. Without that, a compliance sweep firing overnight would mark as superseded the proposal someone had spent the afternoon reviewing — silently, with no decision recorded anywhere. Within a bucket, a new run does supersede the pending remainder, because a fresh run is meant to be a fresh slate; that behaviour can be switched off per run, and accepted or rejected proposals are never touched.
Proposals describing the same cohort are merged across strategies before they are written, on matching cohort attributes plus member overlap, with a stricter overlap threshold the weaker the attribute match. Two rules finding the same team should produce one opportunity, not two.
Superseded is a fourth outcome, not a decision. It means a newer run replaced this proposal. It is not a rejection, not an approval in flight, and a superseded proposal never became a role.
Decommission is a lifecycle, not a delete
Two governance events retire a role: a role certification whose reviewers reject it, where the rule's action is to disable the role, and an administrator deliberately offboarding it. Both do the same thing — create a deprecation plan, approve it, and move it to deprecated with a real sunset date of now plus a grace window, tenant-configurable and thirty days by default.
During the window the role is blocked from new requests but holders keep their access. Nothing is deleted. When the deadline passes, the sunset sweep revokes every holder's grant through the normal provisioning path — so the change reaches the target system rather than only the database — is judged by the recon breaker ledger first (a mass sunset is held, and the role falls back to Deprecated until released; see safety limits) — writes a per-grant audit entry answering "why was this revoked", and moves the role to retired. A plan that fails is collected and reported rather than aborting the sweep for everything else.
Cancelling before sunset restores the role to the stage it actually held when it was scheduled, captured at that moment: a role that was under review returns to under review, a draft returns to a draft. An earlier version reset everything to active, which quietly promoted a draft role into a live one on the way back.
Plans for roles, entitlements and applications are on one page, Retirement, under Governance › Lifecycle: a server-paged list with the plan beside it. A role's own Lifecycle tab shows the same plan facts. From the Roles list, which is now one list over the whole tenant (the separate catalogue and pipeline views were merged), a bulk retire schedules one plan per selected role; there is no bulk recertify.
The business admin can propose retiring an active role from its Lifecycle tab. Approving, deprecating, retiring now and cancelling stay with an administrator, so a proposed plan needs a second person. The proposal lands as a task in the IAM team's inbox, which the proposer cannot decide; approving it approves the plan but does not start the grace period, which stays an act on the Retirement page. An administrator who approves a plan they proposed themselves is allowed, and the plan and its audit event mark it as a self-approval whatever the screen sent. A cancelled plan leaves no "stop granting" mark behind on the role.
Three other places set a "stop granting this" flag on a role — sync drift detection, and the advisers that notice a role with no holders or a dangling organisational reference. Those block new requests and nothing else: no plan, no deadline, no revocation. They are signals, and they are deliberately not this lifecycle.
Known edges, published rather than discovered
- This is not unattended role engineering. Every formalisation passes a named owner and a reviewer chain, by design. There is no configuration that removes either.
- It does not find "the" role model. It proposes candidates against access as observed today. A cohort that shares access for a bad reason still looks like a role; that is what the reviewers are for.
- It sees only what has been connected and reconciled. Coverage counts Expected-access sources, which reconciliation writes — so a tenant that has never reconciled reads near zero coverage, correctly. Access in an unconnected system contributes nothing at all.
- Evidence includes access with no recorded basis, by default. A grant carrying no Expected-access source counts when a cohort's size, coverage or exclusivity is computed, so mining can find roles in a tenant that has governed little so far. The minimum cohort size still applies, and each evidence row shows how many holders are governed and how many are drift. In the New mining run dialog you can untick the option to refine only what is already governed. The coverage numbers are unaffected either way.
- The cohort population excludes terminated identities, held people and offboarded connectors. A leaver whose grants have not yet been revoked never enters a cohort or its coverage/exclusivity math, and neither do the grants of a person who is on hold (locked or not yet activated), or grants on a connector that has been offboarded. Held people's grants are also not counted as covered. Terminated and not-in-target grants still sit outside the tenant-wide coverage figure, which answers a different question (how much currently-held access is explained) than cohort formation does.
- Confidence ranks; it does not predict. It is a fixed weighting of coverage, exclusivity and cohort size. Nothing measures whether high-confidence proposals turn out better.
- Mining revokes nothing by itself. Formalising a role adds structure; it does not remove anyone's existing access. Outliers and missing grants are surfaced as lists, and closing either is a separate, human decision. The formalise step offers an opt-in access review over the people outside the group. It starts when the role is approved (a rejected role starts nothing), creates one attestation per reviewable grant, and a review with no answer after 14 days revokes the access, which the dialog states. If the review cannot be started, the role approval stands and the failure is audited.
- Application roles are excluded from extension proposals. They exist to wrap a directory group family for one application; proposing to extend one with a second application's groups would be semantically wrong.
Further reading: