Skip to content
Sitesh Choudhary
← Projects

IGA Application Onboarding & Connector Integration Playbook

· 1 min read
IGAPlaybookIntegration

A working playbook for onboarding enterprise applications onto an IGA platform, built from integrating a mix of Active Directory, JDBC, web-service, and disconnected applications across a large application portfolio.

Sequencing before integration

Before any technical integration work, applications are classified by three factors: integration complexity, business criticality, and risk posture. This classification drives onboarding order — not “easiest first” and not “highest-risk first” by default, but a sequence that builds integration confidence on lower-risk applications before tackling the connectors and data quality issues that come with critical, complex systems.

Connector decision path

  1. Direct connector available (AD, JDBC, standard web service) — integrate directly, validate against the entitlement catalog and role model rather than importing entitlements as-is.
  2. Custom integration required — evaluate cost against business criticality; a custom connector is only justified if the application is in scope for governance long-term.
  3. No viable connector — route to a manual fulfillment process with defined SLA and reconciliation, rather than excluding the application from governance entirely.

What goes wrong without this discipline

Two failure modes show up repeatedly without a defined onboarding playbook: applications get integrated in whatever order requesters ask for, front-loading complexity before the team has built confidence in the platform; and disconnected applications get quietly excluded from governance because there’s no defined fallback path, becoming a growing blind spot in access certifications and SoD analysis.

Reconciliation as part of onboarding, not an afterthought

Every newly onboarded application goes through a reconciliation pass before it’s considered “live” in the governance program — confirming that what the connector reports matches the target system’s actual access state. Skipping this step is the most common source of an IGA platform’s data silently diverging from reality.