> 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/faq/operations-and-requests.md). # Operations, requests and access Short answers to questions administrators ask most often about operations, requests and access. ## What this is, and when you need it Short answers to the questions this area generates most often, each linking to the page that carries the detail. If your question is not here, the section hubs route by outcome and the [error and symptom index](/administration-guide/error-and-symptom-index.md) routes by the exact message you were given. ### A bulk operation keeps re-entering the provisioning queue and never finishes. What is looping? A message is put back on its own queue for one reason: the save could not proceed because another save of the same user was already running. Each attempt adds `Save is in progress. Send message back to queue. RabbitMQ exchange is ` to the operation's audit event, and on the last attempt the retry stops with `Maximum retry count exceeded. Operation interrupted.` — the ceiling is `org.openiam.rabbitmq.message.max.retry.count`, shipped `100`, counted on the `rabbitmq-message-retry-count` header. Read the audit event for the save that keeps failing; raising the retry count only lengthens the loop. [Full detail](/administration-guide/operations/diagnose-a-failed-operation.md#the-broker-reply-timeout) ### A large directory feed fails with a RabbitMQ delivery acknowledgement timeout. Which timeout is that? The broker's, not OpenIAM's reply timeout — it measures how long one request may occupy a consumer before the channel is closed, and the message states the value in force. Raising OpenIAM's reply timeout does not affect it. Reduce the work in a single request instead: ask a directory for the attributes you actually map rather than every attribute, since the unused ones can include large binary values and nothing downstream can use them. [Full detail](/administration-guide/operations/diagnose-a-failed-operation.md#when-it-goes-wrong) ### A revoke request completed successfully and the role is still on the user. Is the revocation broken? No. Completion end-dates the membership rather than removing it unless `org.openiam.workflow.termination.access.remove` is set, and it ships `false`, so a revoked role stays visible on the user with a date in the past. The same flag governs certification revocations. If your controls assert that revoked access was removed, confirm which behaviour you have before you attest to it. [Full detail](/administration-guide/governance/certification/operate-a-live-campaign.md#remove-versus-end-date) ### A user with permission to edit another user gets "Could not initiate workflow". Where is the real reason? Not on screen. That message is what the UI shows when the workflow service fails or returns nothing to a request to start a flow, and it carries no reason of its own. Read the workflow service log for that minute, then confirm that the request type's approver association resolves to anybody at all — for an edit-user request that is the `EDIT_USER_AR` resource's **Approver Associations** tab. [Full detail](/administration-guide/requests/approval-flows.md#when-it-goes-wrong) ### An approval step we configured never ran and no approver was ever asked. Where did it go? A step whose approver resolves to nobody — an empty approver group, or a target user with no supervisor — is handled by the step's **Required?** setting. A required step falls back to the default approver, and the task shows it, with the approver name reading ` (Default approver)`. A step that is not required is dropped from the request silently, and nothing on any screen reports that a step was removed. [Full detail](/administration-guide/requests/approval-flows.md#change-who-approves) ### Approvals are driven by approvers on roles and groups. When a role has no approver we expected the supervisor, but the request is approved automatically. Can we set a default per step? No — there is no per-step default approver and no automatic fall back to the supervisor, and this is how the feature is built rather than a fault. With `org.openiam.workflow.create.request.rbac.mode` set to `true`, a role or group with no approver association of its own inherits the target resource's associations; where the resource has none either, that sub-request has no approval step and completes on submission. If every request must be approved by somebody, put an association on the target resource, or give each requestable role and group its own. [Full detail](/administration-guide/requests/approval-flows.md#the-properties-that-route-approvals) ### Can we stop the same person from approving two levels of the same request? Not from the Webconsole, and not with a setting — each level resolves its approvers independently, and a delegation can hand a later step to somebody who already decided an earlier one. The one same-person rule in the product concerns the requester, not a repeat approver, and it skips a step rather than blocking one. Where the control matters, build it into the approver associations — different roles or groups per level, with no overlapping membership — and audit that overlap yourself. [Full detail](/administration-guide/requests/approval-flows.md#one-person-approving-more-than-one-level) ### Is there a read-only administrator role, so somebody can look at every screen without changing anything? None ships, and one cannot be built by hiding menu items, because hiding an item does not protect the operation behind it — the operation still answers anyone entitled to a URI pattern that covers it. Entitling a broad console pattern therefore grants the write operations along with the read ones. Build the role from the narrowest set of URI patterns the reader genuinely needs plus the menu items that match, and verify it by attempting a write, not by looking at the navigation. [Full detail](/administration-guide/start/first-login.md#confirm-what-you-can-administer) ### One user's detail screen takes far longer to open than another's, with no change to the environment. What is it doing? Before rendering, OpenIAM asks for each identity on the record whether that user is entitled to the identity's managed system resource, so the wait grows both with the number of identities on the user and with the size of that user's entitlements. Raise `org.openiam.authmanager.service.impl` to `DEBUG` and reproduce: the auth-manager log then prints `is Entitled. Time: . User ID: . Resource ID: ` for each check, which tells you whether the entitlement checks account for the wait. Compare a slow user against a fast one on the same instance rather than against a stopwatch. [Full detail](/administration-guide/operations/which-log-to-read.md#raising-the-detail-level) ### The Save button has disappeared from an edit screen after an upgrade. Is this a release problem? Almost certainly not. Action buttons are menu items in their own right and are entitled like any other, so a button that one role sees and another does not is a menu grant, not a version difference. Grant the button on the role's **Menus** tab, save the menu tree, and allow for the menu and entitlement caches before you conclude it did not work. [Full detail](/administration-guide/start/first-login.md#when-a-menu-change-does-not-take-effect) ### We cleared a menu item's Is Public flag, but users in one role can still see it. What did we miss? `Is Public` adds the item to every user's entitled set; it does not mask a grant that already exists. A role that holds its own grant on the item keeps seeing it after the flag is cleared, so you have to remove the item on that role's **Menus** tab as well. The item's own detail panel lists the users, groups and roles entitled to it, which is the fastest way to see which grant is still in force. The same two checks — the flag and the entitlement list — answer the reverse case, an item a population should see and does not. [Full detail](/administration-guide/start/first-login.md#when-a-menu-change-does-not-take-effect) ### We edited a menu item and saved it, and nothing changed. Why? Edits made in the item dialog are held in the browser until you press **Save Menu Tree** on the tree screen, so closing the dialog and leaving the page discards them. Once the tree is saved, two caches stand between the change and the user: the menu tree itself is rebuilt on the sweep governed by `org.openiam.authorization.manager.menu.threadsweep`, shipped `300000` — five minutes — and each user's entitlements are cached for `org.openiam.authorization.manager.cache.local.ttl.minutes` (shipped `30`) and `org.openiam.authorization.manager.cache.remote.ttl.minutes` (shipped `60`). A user's copy is purged when they sign out, so having the affected person sign out and back in is the quick way to prove a grant landed. [Full detail](/administration-guide/start/first-login.md#when-a-menu-change-does-not-take-effect) ### We removed every approver from the resource, the role and the group, and requests still go to sysadmin. How do we make a request need no approval? There is no configuration that produces a request with no approval step. With no approver association on the target resource, OpenIAM looks for the request type's `_AR` resource, then the resource named by `org.openiam.idm.activiti.default.approver.association.resource.id`, and finally `org.openiam.idm.activiti.default.approver.user` — which ships as the built-in `sysadmin` account. `REVOKE_ACCESS` and `TERMINATE_USER` reach it most often because neither has a seeded `_AR` resource of its own. An approver whose name on the task reads ` (Default approver)` confirms which fallback fired. [Full detail](/administration-guide/requests/approval-flows.md#the-shipped-default-approver-resources) *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 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/faq/operations-and-requests.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.