> 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/integration.md). # Integration: reaching the estate How OpenIAM reaches each system in the estate — which integrate through a shipped connector, which through a generic one, which through a human task, and where the connector processes physically run w ## What this is, and when you need it Part 6 answers a question that sounds operational and is not: **how does OpenIAM actually reach each system in the estate, and what happens to the ones it cannot reach?** It is the part that decides whether the design in Parts 2, 3 and 4 can be executed. A role model whose entitlements cannot be fulfilled is a diagram; a certification campaign whose revoke decisions cannot reach the target is evidence of a control that does not exist; a leaver process that stops at the boundary of an unintegrated application is a leaver process with a hole in it. You need this part while the identity design is still being drafted, not after it. Programmes that leave integration until delivery discover the constraint one application at a time, and each discovery costs a re-plan. The two pages split the question in half. **What each system integrates through** is a capability and governance decision, made per system and usually with the application owner in the room. **Where the connector process runs** is a network and security decision, made once for the estate and then refined per segment. They are settled by different people, and neither is safe to decide without knowing the other's answer. ## The decisions in this part | Decision | Where it is made | What it turns on | | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | How each system integrates — shipped connector, generic scripted connector, custom source adapter, a connector you build, a human task, or nothing | [Connector strategy](/solution-architecture/integration/connector-strategy.md) | Whether a shipped connector **runtime** exists for that system, whether the target has an API at all, and whether its owner will engage | | What to do about a system with no connector | [Connector strategy](/solution-architecture/integration/connector-strategy.md) | Whether manual fulfilment's ceiling is acceptable — a human attests that the change was made, and nothing reads the target back | | Whether an ITSM ticket counts as fulfilment | [Connector strategy](/solution-architecture/integration/connector-strategy.md) | It does not. The hook is a notification, it cannot fail visibly, and the entitlement is saved before it runs | | What can be adapted without writing a connector, and what a new connector costs | [Connector strategy](/solution-architecture/integration/connector-strategy.md) | Whether the gap is in transformation, in matching, in the inbound read or in the protocol itself | | Where connector processes physically run | [Connector placement](/solution-architecture/integration/connector-placement.md) | Where the targets are, and how many network segments they sit in | | How the design reaches targets in several networks | [Connector placement](/solution-architecture/integration/connector-placement.md) | One connector record, one queue and one connector process per segment — there is no site or zone concept to lean on | | What a cloud-hosted platform needs in order to reach on-premise targets | [Connector placement](/solution-architecture/integration/connector-placement.md) | Whether you expose the broker privately, expose it publicly with mutual TLS, or build site-to-site connectivity yourself | | Whether the design needs a Windows Server host at all | [Connector placement](/solution-architecture/integration/connector-placement.md) | Whether any integration requires an operation only PowerShell can perform | | How integration work is ordered across the waves | [Connector strategy](/solution-architecture/integration/connector-strategy.md), then [Phasing a rollout](/solution-architecture/programme/phasing-a-rollout.md) | Connector maturity, target availability and owner engagement — not application importance | ## Start here Read [Connector strategy](/solution-architecture/integration/connector-strategy.md) first, and read it with the application list in front of you. Its opening section is an inventory: six things you have to know per system before the other decisions in this guide can be made honestly. Two things it establishes are worth knowing in advance, because both close off assumptions designs routinely make. **A seeded managed-system definition is not a shipped connector.** OpenIAM's database carries connector records and policy-map templates for integrations whose runtime is not in the shipped distribution. Confirm availability per system with OpenIAM before a design depends on one. **Manual fulfilment is a real design option with a governance ceiling.** A managed system can be flagged manual, and an approved request against it becomes a human task rather than a connector call — which is how badge systems, key cabinets and vendor portals get governed. But nothing reads the target, so it is attestation rather than verification, and a pending manual entitlement is excluded from certification. Choosing it without knowing that trades a control for a workflow. ## What this part does not cover Part 6 stops at the decision. Configuring a managed system, building a policy map, writing the Groovy a scripted connector runs, and proving a connection works belong to the **Administration Guide**; installing and upgrading a connector host belongs to the **Installation Guide**. How many machines, of what shape, is in [Deployment architecture, scale and environments](/solution-architecture/deployment.md), which assumes the placement decisions made here. Where a second governance platform is live, the ownership rule in [Coexisting with an incumbent IGA](/solution-architecture/coexistence/coexisting-with-an-incumbent-iga.md) constrains this part directly: the platform that owns an application owns its provisioning path, and a "temporary second connector" breaches that rule rather than preparing for it. ## Related * [Connector strategy](/solution-architecture/integration/connector-strategy.md) — the inventory, the options and what happens when there is no connector. * [Connector placement](/solution-architecture/integration/connector-placement.md) — where the processes run, across how many networks, and what each host must reach. * *Connectors and managed systems* and *Shipped connectors* in the Administration Guide — what a connector is, and the catalogue this part reasons about. *Applies to OpenIAM 2026.8.1. Last reviewed 13 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/integration.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.