> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/caddie/revocation-impact.md).
# What happens if I revoke this?
For reviewers — the Caddie — Access Review Assistant block "What happens if I revoke this?", which predicts a revocation before it is made: when the access would end, which resources would be lost and
Reviewers approve because revoking feels dangerous and approving feels free. The reviewer screen has never answered the one question behind that feeling: *what would actually happen if I took this away?* The block titled **What happens if I revoke this?** answers it, for one line item, before the decision is made. It states consequences, it is explicit about what OpenIAM cannot see, and it never suggests a decision.
**On this page**
* [What the block is](#block-revocation-impact)
* [When a revocation takes effect](#impact-timing)
* [What the person would lose, and what they would keep](#impact-lost-kept)
* [What would happen to the accounts](#impact-accounts)
* [Warnings worth reading before deciding](#impact-warnings)
* [Separation of duties](#impact-sod)
* [What OpenIAM cannot tell you](#impact-limits)
* [The partial answer](#impact-partial)
* [What the block does not do](#impact-read-only)
## What the block is
The block is a list of plain sentences, in the order a reviewer needs them: when the change would take effect, what would be lost, what would survive, what would happen to the person's accounts, and only then the warnings that make a revocation pointless or costly in some other way. The separation of duties (SoD) outcome comes last, because it is the one consequence the screen already hints at elsewhere.
It loads in two tiers. The facts the row itself proves, an end date, a business-rule tag, an open SoD violation, appear the moment you expand the block. The rest, which needs the entitlement graph, arrives a moment later and replaces them. Nothing is requested until the block is expanded.
For Tom Becker's `Payments-Admin`, the block reads:
> The access would end on the day this review is completed. The membership is end-dated, not deleted. Tom Becker would lose access to: Payments Console, Payments Approvals. The account tbecker on Payments would be disabled. This access is set to expire on Nov 12, 2026 anyway. OpenIAM cannot tell whether this access is in use, or which application functions depend on it.
## When a revocation takes effect
The first sentence is usually the surprising one: a revocation is **not** applied when you click it, and not when you submit. It is applied when the reviewed person's whole review is finished. Until then the item simply carries the decision.
What happens then depends on one deployment-wide setting, which ships switched off:
| The block says | Meaning |
| ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| *The access would end on the day this review is completed. The membership is end-dated, not deleted.* | The default. The membership row gets an end date, so the record that the access once existed survives |
| *The access would be removed on the day this review is completed.* | Your administrator switched `org.openiam.workflow.termination.access.remove` on. The membership row is deleted |
Either way the same provisioning update follows, so the difference is only in what OpenIAM keeps afterwards.
## What the person would lose, and what they would keep
This is the heart of the block, and the half the reviewer screen has never shown.
An entitlement grants a set of resources. Some of those the person may also reach through another role, group, organization or a resource granted to them directly, and provisioning removes a resource **only when the revoked access was the last path to it**. The block runs exactly that arithmetic, read-only, against the same entitlement graph provisioning consults, and reports both halves.
| Situation | The block says |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Something would be lost | *Tom Becker would lose access to: Payments Console, Payments Approvals.* Up to ten resources are named, then *and {n} more* |
| Every resource survives through other access | *Revoking this access would not remove access to any resource: everything it grants is also granted by other access Maria Rossi holds.* |
| The entitlement grants no resources at all | *This access grants no resources, so nothing would be removed from any system.* |
What survives is listed one resource at a time, with the access that keeps it: *Maria Rossi keeps Finance Dashboard through Finance-Controllers.* After ten, *{n} more resources would also be kept through other access.*
The reach is **transitive**. A group that grants a role that grants a resource reports that resource, because that is what would actually be de-provisioned. This matters for group rows in particular: only direct memberships are reviewable, so revoking a group takes everything reachable from it while you see a single row.
## What would happen to the accounts
Resources are an internal abstraction; accounts are what you recognise. For every managed system the person actually has an account on, and whose backing resource would be de-provisioned, the block says what would become of that account:
| The block says | Why |
| ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| *The account tbecker on Payments would be deleted.* | The system's resource has no `ON_DELETE` setting, so provisioning applies its default: delete |
| *The account tbecker on Payments would be disabled.* | The system is configured with `ON_DELETE = DISABLE` |
| *The account tbecker on Payments would be updated.* | Any other `ON_DELETE` value |
| *Payments is managed manually: an administrator would receive a task to remove the access.* | The managed system has no connector, so a person does the work |
When the login is not known the sentence drops it: *The account on Payments would be disabled.* Systems the person has no account on are not mentioned; there is nothing there to lose.
## Warnings worth reading before deciding
These are the consequences nothing else on the screen surfaces.
| The block says | What it means for your decision |
| --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| *A business rule currently assigns this access; it would be granted again automatically.* | The same provisioning run that removes the grant would give it straight back. Revoking changes nothing except the audit trail; the fix is the rule, and that is a note to your administrator |
| *This access is assigned to all users; it would be granted again.* | The entitlement is marked for everyone. The next provisioning run restores it |
| *This membership makes Tom Becker an owner or administrator of Payments-Admin; revoking it removes that.* | With the ownership goes whatever routing depends on the entitlement having an owner, including who is asked for help about it |
| *Tom Becker would no longer be part of the approver group Payments-Approvers.* | Where an approver association names the role or group as an approver, revoking the membership quietly changes who signs off future requests |
| *This access is set to expire on Nov 12, 2026 anyway.* | Read from the live membership, not the campaign's launch snapshot, so a grant re-dated since launch is reported as it stands today |
## Separation of duties
Where the item takes part in a still-open SoD violation, the block first names it, from what the row already knows: *This access takes part in an open separation-of-duties violation of the policy Payments Four-Eyes.* Once the full answer arrives it says what revoking would do about it:
* *Revoking this access would resolve the separation-of-duties violation Payments Four-Eyes.*
* *Revoking this access would not resolve Payments Four-Eyes: 2 other conflicting items remain.*
The count is the campaign's own arithmetic. A segment stays triggered while the number of the person's conflicting items in it reaches the segment threshold, and the policy stays violated while the number of triggered segments reaches the policy threshold. It is the same test the resolution dialog previews and the same one the campaign applies when it auto-resolves violations after a decision is recorded, so the three always agree. Working a violation to closure is described on [Work an SoD violation to closure](/administration-guide/governance/sod/sod-triage-remediation-and-evidence.md).
## What OpenIAM cannot tell you
The block ends, every time, on the same line:
> OpenIAM cannot tell whether this access is in use, or which application functions depend on it.
This is part of the answer, not a disclaimer. *Nothing would be lost* is an accurate sentence that is easily read as *nothing would break*, and it is not the same claim. Beyond usage, the prediction cannot cover access re-granted by synchronization transform scripts or by custom Groovy processors, nor anything an application does internally with the access. Those are the things you know about the business and the block does not; if they matter, write them in your note.
## The partial answer
Working out what would be kept costs one entitlement-graph traversal per other membership the person holds. The traversals run in parallel under a bound and share a time budget, five seconds by default. If the budget runs out, the block says so:
> The full list of affected resources could not be computed in time; the other facts above still apply.
The resource and account lists are then left out entirely rather than shown empty. *We could not work it out* and *nothing would be lost* are different statements, and only one of them is safe to act on. The bounds are system properties your administrator can change; see [System properties that tune the blocks](/administration-guide/caddie/enable-caddie.md#enable-properties).
## What the block does not do
Nothing here writes anything. Expanding the block records no decision, changes no review state, sends no provisioning or workflow message, and leaves no audit entry. It predicts a revocation; it never performs one. The certify and revoke toggle on the row is the only thing that does.
## Related
* [Operate a live campaign](/administration-guide/governance/certification/operate-a-live-campaign.md) — what a revoke decision actually does once the review completes
* [Work an SoD violation to closure](/administration-guide/governance/sod/sod-triage-remediation-and-evidence.md) — the resolution dialog that uses the same arithmetic
* [Ask for help](/administration-guide/caddie/ask-for-help.md) — when even this does not settle it
* [Enable Caddie](/administration-guide/caddie/enable-caddie.md#enable-properties) — the time budget, parallelism and list limits
*Applies to OpenIAM 2026.9.2. Last reviewed 23 September 2026.*
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.openiam.com/administration-guide/caddie/revocation-impact.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
