> 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/the-enterprise-view.md). # The enterprise view without duplicate governance Read-only synchronization of another platform's access data — what a unified view can answer, what OpenIAM can actually ingest and represent, and how to stop visibility becoming a second set of govern ## What this is, and when you need it While two governance platforms are running, somebody has to be able to see across both. A manager approving a transfer, a reviewer preparing a campaign, an auditor sampling a quarter — none of them care which platform governs which application, and all of them will ask for one screen. That screen is achievable, and it is the main thing the coexistence period delivers beyond simply not breaking. The decision this page settles is **how much of the other platform's access data to bring into OpenIAM, and how to keep the copy observational** — because a unified view that quietly turns into a second set of governance is worse than no unified view at all. ## The decision | Approach | What it gives you | What it costs | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **No unified view** — each platform reports on its own estate | Nothing to build; no risk of duplicate governance | Two lists rather than one picture. Any cross-estate question is answered by a person with a spreadsheet, on request, at the quality of that person's afternoon | | **Periodic extract into a reporting tool** | Cheap; keeps both platforms untouched | The extract has no identity model, so it cannot answer anything the two extracts do not already share. It ages between runs and nobody can say how much | | **Read-only ingestion into OpenIAM** (recommended) | One identity model spanning both estates; the access appears against the person, in OpenIAM's reports, alongside the access OpenIAM governs | A feed per application to build and operate; the representation is thinner than governed access in specific ways, named below; discipline required to keep it read-only | | **Full ingestion with governance** — import the access and certify it in OpenIAM | The apparent completeness the audit function asks for | It breaks the single-writer rule. OpenIAM can collect a revoke decision it has no write path to execute, and the campaign produces evidence of a control that does not exist | **Ingest read-only.** The rest of this page is what OpenIAM can actually represent, how the read-only property is assembled, and where the representation falls short of the ideal — which it does, in ways worth knowing before you promise the screen. ## What a unified view is asked to answer Four questions come up in every review of this design. It is worth being explicit about how well each one is answered for access that OpenIAM did not grant. | Question | For access OpenIAM governs | For access imported from an incumbent-governed application | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Which platform governs it?** | Fully answered | Fully answered, and it is the easiest of the four: roles and groups are scoped to a managed system, so the application the entitlement belongs to is part of the record | | **When was it provisioned?** | Fully answered — the membership carries its creation, start and end dates, and the provisioning is in the audit trail | **Partially.** The membership records when OpenIAM first saw the entitlement, not when the incumbent granted it. Unless the source feed carries a grant date you can map onto the membership's start date, the earliest reliable statement is "present at the first import" | | **Why does this access exist?** | Answered structurally — birthright rule, role membership, or a request with its own record | **Thin.** What you get is that the person holds an entitlement in an application, and which feed created the record. Any business reason lives in the incumbent, and comes across only if the source feed carries it as an attribute you deliberately map | | **Who approved it?** | Fully answered — the request and its approval decisions | **Not answered.** The approval record stays in the incumbent. The imported membership names the feed that created it, not a human approver. Do not let this be presented as an approval trail | Two of the four are answered well and two are not. Say so early. An audit function told that OpenIAM will show *who approved* every access across both estates has been promised something the design does not deliver, and the discovery usually happens in front of the auditor. ## What OpenIAM can ingest The enterprise view is assembled from ordinary synchronization and reconciliation against the applications themselves — not from an integration with the incumbent platform, which does not exist. That constrains what is available, and it is worth knowing the shape of it before designing the feeds. **Objects.** A synchronization's **Synchronize Object** setting selects what the feed carries: users, roles, groups, organizations, resources or managed systems. That is enough to import an application's account list *and* its entitlement catalogue — the roles and groups the application defines — rather than only the memberships. **Sources.** A feed can read a CSV file, a relational database over JDBC, a connector operating asynchronously, or a custom adapter, and can run as a full or an incremental synchronization. In practice the incumbent estate arrives one of two ways: directly from the applications through their connectors, or as an extract the incumbent's owners produce on a schedule. The first is better — it is the application's own truth rather than the incumbent's belief about it — and it is the one to ask for. **Entitlement memberships.** Attaching an imported entitlement to a person is done in the feed's transformation rule. A shipped sample transformation script demonstrates the pattern for a CSV carrying an application name, an entitlement type of role or group, and an entitlement name: it resolves the managed system by name, finds the role or group scoped to that managed system, and adds the membership to the person. That per-managed-system scoping is what makes the resulting view answerable by application. **Accounts that do not correlate.** A feed with **Detect orphans** set records an account it cannot match to an identity as an orphan rather than failing the run, under the `SYNCHRONIZATION_ORPHAN` audit action. Orphans are visible on the **Orphan Management** screen, where they can be linked to a user, and in the `ORPHANED_USER_ACCOUNTS` report. During coexistence, orphan volume is the best single measure of whether the correlation key is good enough — see Part 2, *Identity correlation: choosing a matching key*. **Reporting.** The imported access lands in the same place as governed access, so the shipped reports reach it: `USER_ACCESS_REPORT`, `ENTITLEMENTS_REPORT`, `ENTITLEMENTS_MEMBERSHIP_REPORT` and the reconciliation and synchronization run reports. This is the practical form of "one screen". ## How the copy is kept read-only Read-only is not a mode you switch on. It is a property you assemble from three independent settings, and it holds only as long as all three do. **The reconciliation's situation responses.** A reconciliation configuration maps each of the four situations to a response. The four situations are OpenIAM \[exists] with target \[exists], OpenIAM \[exists] with target \[not found], target \[exists] with OpenIAM \[not found], and OpenIAM \[deleted] with target \[exists]. The responses divide cleanly into those that write into OpenIAM — *Add Record to IDM from Resource*, *Update IDM from Resource*, *Delete from IDM*, *Remove from IDM*, *Disable (or change status in IDM)* — and those that write to the application: *Add Record to Resource from IDM*, *Update Resource from IDM*, *Delete from Resource*, *Disable (or change status in Resource)*. Configure only from the first group, and *Do Nothing* where you want no action. Configured that way the reconciliation can see everything and change nothing. Two cautions on that list. *Do Nothing and Inform* and *Disable (or change status in Resource)* appear in the response drop-down but have no built-in user command behind them; selecting either without supplying a custom command script fails the run with a configuration error rather than doing nothing. And the group reconciliation supports a smaller set of responses than the user reconciliation does. Prove your configuration on a non-production instance rather than reasoning from the drop-down. **The synchronization's provisioning setting.** A synchronization carries **Provision to target systems?** Cleared, the feed writes to OpenIAM's own records only. Its help text warns that identities must then be created in the transformation script, which is a real consequence and the reason this setting is sometimes set the wrong way by someone debugging a feed. **The managed system's simulation list.** Selecting every provisioning operation on the managed system means any write OpenIAM attempts against that application — from any path, not only the feed — is captured for review instead of dispatched. This is the backstop for the other two, and the only one of the three that catches a write originating somewhere you did not think about. Use all three. Each closes a different door, and the failure you are guarding against is not a misconfigured feed but a well-intentioned change made months later by someone who was not in this design review. ## Where the representation is thinner than the ideal Beyond the approval provenance already named: **Imported access is not certifiable access.** OpenIAM can display and report on an entitlement it did not grant. It cannot revoke one in an application it has no write path to. Keeping imported access out of campaign scope is therefore not a preference but a requirement — a campaign that collects decisions it cannot enforce degrades the certification evidence for everything else in the same campaign. **Imported memberships are hard to tell apart on sight.** An entitlement imported from an incumbent-governed application and one OpenIAM granted are the same kind of object. Nothing in the model marks one as observed. Making the distinction visible — through the managed system the entitlement is scoped to, through naming, or through membership tags — is a design task, and if it is skipped somebody will eventually try to revoke an imported membership and quietly succeed in removing it from OpenIAM while it remains live in the application. **The view is as fresh as its last run.** Reconciliation is scheduled, not event-driven. State the interval in the design and in whatever the audit function is shown, because "current" will otherwise be assumed. **Deletion in the application is not a lifecycle signal.** An account that disappears from the target produces the OpenIAM \[exists] with target \[not found] situation, and what happens next is whatever you configured — which, in a read-only design, should usually be *Do Nothing* or a status change inside OpenIAM, never an action against the person's other access. ## What we recommend **Build the enterprise view first, before the first application migrates.** It is achievable early, it is what makes running two platforms defensible, and it produces the correlation evidence the wave plan needs anyway. **Read the applications, not the incumbent.** Where you have a choice between the incumbent's export and the application's own connector, take the connector. It is the truth the auditor will test against, and it survives the incumbent's retirement unchanged. **Assemble read-only from all three levers, and record that you did.** The design should say which reconciliation responses are configured, that the feed does not provision, and that the managed system's simulation list is full. That paragraph is what a reviewer checks a year later. **Do not certify what you cannot revoke.** Keep imported access out of OpenIAM campaigns until the application's wave has completed. If the audit function needs attestation of that access in the meantime, it is the incumbent's campaign that provides it. **Say plainly which of the four questions the view answers.** Governs and when-first-seen, yes; why and who-approved, only as far as the source feed carries them. Promising four and delivering two is how a good design acquires a bad reputation. **Treat orphan volume as the health metric for the whole arrangement.** Rising orphans mean the correlation key is failing, and every downstream claim — the view, the wave plan, the transfer case — degrades with it. ## What OpenIAM does not do here * **There is no connector to another governance platform.** The enterprise view is built from the applications, in the same way OpenIAM reads any managed system. * **Approval history does not come across.** OpenIAM has no way to represent an approval that happened in another platform, and no field that would hold it if the feed carried one. * **Imported access cannot be revoked in the source application.** Removing the membership in OpenIAM removes OpenIAM's record of it and nothing else. * **There is no "observed" flag on a membership.** The distinction between governed and imported access is one you have to design into naming, scoping or tagging. * **A reconciliation is not a real-time view.** It runs to a schedule; between runs the picture is as old as the last run. * **The response drop-down offers more than the product implements.** *Do Nothing and Inform* and *Disable (or change status in Resource)* have no built-in user command; a run configured with either fails rather than proceeding. ## Related * [Coexisting with an incumbent IGA](/solution-architecture/coexistence/coexisting-with-an-incumbent-iga.md) — the rule this page keeps you inside. * [Planning a wave migration](/solution-architecture/coexistence/planning-a-wave-migration.md) — how observed access becomes governed access. * Part 2, *One person, many accounts* — how the accounts you import attach to a single identity. * *Set up a synchronization*, *Configure reconciliation* and *Plan and scope a campaign* in the Administration Guide — the mechanisms and the campaign scoping rules. *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/the-enterprise-view.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.