Connector flow
How a connector establishes a session and exchanges data with a managed system.
A connector authenticates to the target, reads or writes accounts and entitlements, and returns results to the aggregation or provisioning engine.
- Purpose: exchange account and entitlement data with a managed system
- Trigger: An aggregation or provisioning operation
- Outcome: Data read from or written to the target, with results returned
- Where it fits in the SailPoint architecture
The connector flow is what happens each time IdentityIQ exchanges data with a managed system, during both aggregation (reading) and provisioning (writing). The connector is the bridge between SailPoint's model and the target's native reality, and most integration problems are, at root, connector-flow problems.
What triggers the flow
A connector operation runs whenever an aggregation reads a source or a provisioning action writes to a target. The same connector typically handles both directions for a given application.
Step by step
- 1. Load configuration. The connector reads its settings, host, credentials, schema mapping, options, from the application object.
- 2. Authenticate. It establishes a session with the target using the configured credentials (service account, API token, OAuth client).
- 3. Read or write. For aggregation it iterates accounts and entitlements; for provisioning it applies the operations in the provisioning plan.
- 4. Map data. Native fields are translated to and from IdentityIQ's schema (account attributes, entitlement values).
- 5. Return results. Success or failure, with detail, is returned to the aggregation or provisioning engine and surfaced for troubleshooting.
Connector types
Connectors come in families: directory (AD, LDAP), database (JDBC), API/REST (the Web Services connector, and many SaaS-specific connectors), SCIM, and application-specific (SAP, Salesforce, Workday). Where no standard connector fits, a custom connector implements the connector interface in Java. Each shares this same flow but differs in how it authenticates and speaks to the target.
Schema mapping: the quiet essential
The connector flow only produces correct data if the schema is mapped correctly, which native attribute is the account identity, which is the display name, which values are entitlements, and which attribute drives correlation. A mis-mapped schema aggregates data that then fails to correlate or provisions the wrong attribute, so schema configuration deserves careful attention and testing.
Reading failures
When a connector operation fails, the error returned is your starting point. The recurring culprits are credentials (expired or insufficient rights), network/firewall access to the target, and schema mismatches. Testing raw connectivity to the target, independently of IdentityIQ, quickly isolates network and credential issues from configuration ones.
Common pitfalls
- Service-account rights too narrow to perform the required reads or writes.
- Firewall or network paths not open from the task/VA host to the target.
- Schema mapping errors that break correlation or provisioning downstream.