Connector flow

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.

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.

• 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.

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.

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.

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.

• 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.