> 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/solution-architecture/coexistence/where-a-request-lives.md). # Where a request lives when two catalogues exist When two catalogues exist, the request stays with the application owner — the user crosses the federation bridge, the request does not. One catalogue, one approval policy, one connector, one provision ## What this is, and when you need it Two platforms are live, each with its own request catalogue, and a user needs access to an application the other one governs. Somebody has to decide where they ask. The answer is short and it is worth stating before the reasoning: **the request lives with the application's owner, and the user goes there.** What crosses between the estates is the person — through the federation bridge, as an authenticated session — not the request, not the approval and not the fulfilment. You need this decision as soon as a self-service catalogue exists on both sides, which is usually earlier in the programme than anyone expects. ## The decision | Where the request is raised | What it buys | What it costs | | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **In the catalogue of the platform that owns the application** (recommended) | One request record, one approval trail, one fulfilment record, one place that can answer whether the access was granted. The evidence matches the ownership | The user has two places to go during the transition, and has to know which. Mitigated by federation, deep links and a single starting point, not by routing | | **In the user's home catalogue, handed off to the other platform** | Feels seamless; one front door | Two records for one grant, in two audit trails, with no arbiter when they disagree. The approving platform cannot confirm fulfilment; the fulfilling platform has no approval of its own. It is the split-by-function failure arriving through the front door | | **Duplicate catalogue entries in both platforms** | Users find the application wherever they look | Two approval policies drift apart within a quarter. The same access is granted under different rules depending on where it was asked for, which is very hard to explain and impossible to certify | | **No self-service for cross-boundary access — a service desk ticket** | Simple; unambiguous; sometimes the right answer for a handful of applications | Loses the request record entirely unless the service desk is itself integrated. Access arrives with a ticket number instead of an approval | ## Why routing the user beats routing the request The four things named on [Coexisting with an incumbent IGA](/solution-architecture/coexistence/coexisting-with-an-incumbent-iga.md) — the catalogue entry, the approval policy, the provisioning path and the certification — are the same four things here, seen from the user's side. Routing a request across the boundary separates the first two from the second two by construction. Routing the user leaves all four together and moves the only thing that can safely move. There is also a plainer argument. A request that has been handed off has two states at once: submitted in one platform, and something-or-other in the other. When a user asks where their request has got to, the platform they asked in cannot tell them, and the platform that knows has no record of who asked. Every organization that builds this eventually builds a status-synchronization job on top of it, and that job is where the design's remaining credibility goes. The counter-argument is real and should be conceded rather than dismissed: it *is* worse for the user. The mitigation is not to route the request but to make the crossing cheap — a working federation trust in both directions, a link from each platform's catalogue to the other's, and an entry experience that does not care where the user started. That is an authentication and navigation problem, and it has good answers; see [Cross-organization federation](/solution-architecture/coexistence/cross-organization-federation.md) and Part 3, *Entry points and the user's experience*. ## Meeting users where they are A related instinct causes as much damage as request routing: deciding that during the migration everyone will use the new portal, and that bookmarks and deep links are a transitional inconvenience. They are not. A user with twenty bookmarked applications will keep using them, and a design that only works from the portal produces a launch full of support tickets that are all the same ticket. Design so that all three entry points work. A user arriving at the application's own URL should be redirected to authenticate and returned; a user starting at their portal should be able to launch the application from there; a deep link into a particular page of an application should survive the authentication round trip. OpenIAM supports both service-provider-initiated and identity-provider-initiated single sign-on, and identity-provider-initiated sign-on is recorded distinctly in the audit log under the `SAML_IDP_INITIATED_SSO` action, so the two remain separable in evidence. The principle generalises past this page: **work the way the user works, rather than making the user work the way the platform does.** In a coexistence programme it is also self-interested. The migration will be judged by the people whose bookmarks stopped working. ## What "one catalogue" requires you to model The rule presumes each application has an identifiable owner and that the owner's decision rights are modelled rather than remembered. OpenIAM has the pieces for this, and they are worth naming because coexistence programmes tend to discover them late. An application's people are modelled as associations — an application owner and an application administrator, an entitlement owner and an entitlement administrator, alongside the generic owner and administrator associations. Who must approve is configured as an **Approver Association**, and the approver can be a specific user, the requester's supervisor, an organization reviewer, a role, a group, or the owner or administrator of the thing being requested. What the requester has to supply is configured with the catalogue entry itself. Two consequences for the coexistence design. First, an application whose owner is unclear cannot be migrated cleanly, because the wave has nobody to accept the approval policy: settle ownership as part of wave preparation, not after it. Second, approval by *owner* or *administrator* is the form that survives a migration best, because it follows the association rather than naming an individual who may have moved during the programme. ## Where there is no connector An application can have a single catalogue entry, a single approval policy and a single certification owner without OpenIAM being able to provision it. Marking the managed system **Manual** makes an approved request produce a human task instead of a provisioning call; the fulfiller does the work in the target and records completion. Revocation behaves the same way — access to automated applications is removed immediately, and non-automated applications produce manual tasks. This is the right pattern for badge systems, key cabinets, mainframes reached by a terminal and vendor portals with no API, and it means "no connector" is not by itself a reason to leave an application with the incumbent. It is a poor reason to move one the incumbent already provisions automatically, and it should not be used to hit a wave date — see the fulfilment row in the ownership table on [Coexisting with an incumbent IGA](/solution-architecture/coexistence/coexisting-with-an-incumbent-iga.md). ## What we recommend **Keep the request with the application owner, always, and do not make exceptions for VIP populations.** The exception population is the one whose access an auditor samples. **Invest the effort you did not spend on request routing into the crossing.** Both directions of the federation trust, a visible link between the two catalogues, and deep links that survive authentication. That is a week of work that removes most of the user-experience objection. **Settle each application's owner before its wave, not during it.** An unowned application has no approval policy to transfer, and the wave will stall on a question nobody in the room can answer. **Prefer owner and administrator approvers over named individuals.** They survive reorganization, which a multi-quarter migration guarantees. **Do not build a status bridge between the two catalogues.** If you find yourself designing one, the routing decision above was made the other way somewhere, and the bridge is the symptom rather than the fix. **Support portal, bookmark and deep link from day one.** Not as a later phase. The launch is the moment the design is judged. ## What OpenIAM does not do here * **OpenIAM does not route a request across a federation trust.** A request raised in one platform's catalogue cannot be approved or fulfilled in another platform's. * **There is no shared approval inbox.** An approver who works in both estates has two task lists, and no product setting merges them. * **A federation assertion carries no request and no entitlement.** It carries an authentication event and attributes. What the receiving platform grants is decided from the receiving platform's own records. * **There is no cross-platform request status.** Neither platform can report on the other's requests, and nothing in the product reconciles them. * **Manual fulfilment records that work was done, not that it was done correctly.** The completion is a human assertion; only a reconciliation against the target confirms it. ## Related * [Coexisting with an incumbent IGA](/solution-architecture/coexistence/coexisting-with-an-incumbent-iga.md) — the four things a request is one of. * [Cross-organization federation](/solution-architecture/coexistence/cross-organization-federation.md) — how the user gets to the other catalogue. * Part 3, *Entry points and the user's experience* — portal, bookmark and deep link as a design decision. * *The request catalog and questionnaires*, *Approval flows* and *Manual fulfilment* in the Administration Guide — how the catalogue, the approvers and the human task are configured. *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/solution-architecture/coexistence/where-a-request-lives.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.