> 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/requests.md). # Configure requests and approvals How a request becomes access in OpenIAM — the catalog that offers it, the approval flow that decides it, and the fulfilment that delivers it. ## What this is, and when you need it This section is for the administrator who has to let people ask for access rather than be given it: what appears in the SelfService catalog, what the requester is asked in return, who decides, in what order, and how the access finally appears in the target. A request travels three configurable stages, each a different set of OpenIAM objects, and almost every "requests are broken" ticket is really a question about which stage you are looking at. | Stage | The question it answers | The page that owns it | | ----------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Request** | What can someone ask for, and what are they asked in return? | [The request catalog and questionnaires](/administration-guide/requests/request-catalog.md) | | **Approve** | Who decides, in what order, and what happens on each outcome? | [Approval flows](/administration-guide/requests/approval-flows.md) | | **Fulfil** | How does the access actually appear in the target? | [Manual fulfilment](/administration-guide/requests/fulfilment.md) | The first two are configuration you build. The third is usually automatic and invisible — the connector and the policy map do it — and only becomes a task when the target has no connector. ## Start here 1. [The request catalog and questionnaires](/administration-guide/requests/request-catalog.md) — nothing can be approved until something is requestable. 2. [Approval flows](/administration-guide/requests/approval-flows.md) — then decide who approves it, because the shipped answer is `sysadmin` for everything. 3. [Manual fulfilment](/administration-guide/requests/fulfilment.md) — last, and only for targets OpenIAM cannot provision to. Read [Change configuration safely](/administration-guide/start/change-safely.md) once before your first change. ## Choose your outcome | I want to… | Go to | | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Make a role, group or application requestable in SelfService, or attach questions to it | [The request catalog and questionnaires](/administration-guide/requests/request-catalog.md) | | Change who approves, add an approval step, edit a flow's shape, or find out why a request is stuck | [Approval flows](/administration-guide/requests/approval-flows.md) | | Raise a ServiceNow incident when a request is approved | [Raise a ServiceNow incident from an approval](/administration-guide/requests/approval-flows/raise-a-servicenow-incident.md) | | Route access in a system OpenIAM cannot provision to a human, and prove it was done | [Manual fulfilment](/administration-guide/requests/fulfilment.md) | | Look up an APPROVER\_ASSOC column, an approver entity type, or what the shipped flow does on approve | [Approver associations and the shipped flow shape](/administration-guide/requests/approval-flows/approver-association-reference.md) | | Look up which BPMN definition drives an approval, and its process id | [Shipped approval workflows](/administration-guide/reference/shipped-workflows.md) | | Look up the reminder and escalation batch tasks, and whether they ship enabled | [Shipped batch tasks](/administration-guide/reference/shipped-batch-tasks.md) | | Look up the workflow variable names to collect from a stuck request | [Enumerated value reference](/administration-guide/reference/enums.md#workflow-variables) | | Look up a property key in the `Workflow` category | [System property reference](/administration-guide/reference/system-properties.md#workflow) | | Review, rather than grant, the access people already hold | [Govern access](/administration-guide/governance.md) | ## Three shipped defaults to know before you start These are stated once here because they change what all three pages mean, and all three surprise people. {% hint style="danger" %} **Every approval routes to `sysadmin` out of the box.** OpenIAM ships 45 `ACTIVITI_REQUEST` resources and 45 matching `APPROVER_ASSOC` rows, and all 45 have `APPROVER_ENTITY_ID = '3000'` — the built-in `sysadmin` account. So do `org.openiam.idm.activiti.default.approver.user` (`3000`) and the fallback resource `CREATE_USER_REQUEST_APPROVERS_AR`. Requests are not stuck; they are correctly assigned to an inbox nobody reads. Reassigning them is part of installing OpenIAM. See [Approval flows](/administration-guide/requests/approval-flows.md#the-shipped-default-approver-resources). {% endhint %} {% hint style="warning" %} **Approvals do not chase themselves.** The `REQUEST_REMINDERS` and `REQUEST_ESCALATION` batch tasks both ship **disabled**, so everything you configure in `DAYS_BEFORE_REMINDER`, `NUMBER_OF_REMINDERS` and the `ESCALATION` rows is inert until you enable them in **Administration → Batch Tasks**. See [Shipped batch tasks](/administration-guide/reference/shipped-batch-tasks.md). **The catalog is permissive by default.** `org.openiam.authorization.create.request.disabled` ships `true`, and the name inverts the meaning: `true` *disables* the entitlement check, so every active application category is visible to every requester. See [The request catalog and questionnaires](/administration-guide/requests/request-catalog.md#step-1-application-categories). {% endhint %} *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/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.