Most engineers think…
Most candidates describe SailPoint as 'a tool that pulls accounts from Active Directory.' That half-answer loses marks in interviews and leaves gaps in production deployments.
SailPoint's true power is multi-source identity correlation: it connects to every authoritative and managed system — AD, HR, SaaS apps, databases — via sources and connectors, runs account and group aggregation, applies correlation rules to stitch raw accounts onto a single identity cube, and then uses provisioning connectors to write changes back. Understanding that full loop — onboarding mechanics in, governance action out — is what separates a SailPoint engineer from a SailPoint user.
① Sources and connectors — the bridge between ISC and target systems
A source in SailPoint Identity Security Cloud (ISC) is the configuration object that represents a target system: Active Directory, Workday, Salesforce, a database, an on-prem app. A connector is the technical bridge — the library or service — that actually speaks the target system's protocol (LDAP, SCIM, REST, JDBC). You always configure a source; the connector is what runs underneath it.
Every source has an account schema that tells ISC which attributes to read. Two special attributes must always be set: Account ID (the stable unique key, e.g. sAMAccountName) and Account Name (the display label). Get these wrong and correlation breaks for every account on that source.
By default every new source is read-only — it can aggregate but not provision. Deep governance features (provisioning, password management, group management) must be explicitly enabled in the source's Base Configuration. This default-safe posture is deliberate: onboard first, govern second.
New sources start read-only by design. Onboard, aggregate and correlate first — confirm the data looks right in ISC — before you enable provisioning. Enabling provisioning on a misconfigured source can propagate bad data at scale.
Which two schema attributes MUST always be set on a SailPoint source?
② VA-based connectivity vs SaaS Connectivity — choosing the right bridge
SailPoint offers two connectivity models. VA-based (Virtual Appliance) connectors run inside your network on a VA cluster — a pair of lightweight Linux VMs you deploy in your data centre or private cloud. The VA reaches out to ISC over HTTPS, so no inbound firewall holes are needed. VA-based connectors are the right choice for on-premises systems, legacy apps and anything that cannot expose a public API.
SaaS Connectivity (the SaaS Connector framework) is SailPoint's cloud-native bridge for cloud-to-cloud integrations. Connectors built on this framework run in SailPoint's own cloud infrastructure, connect to SaaS targets directly over the internet, and need no VA at all. SailPoint publishes a growing library of SaaS connectors (Okta, GitHub, Google Workspace, Slack, and many others), and the open SDK lets customers build custom ones in TypeScript.
Decision rule
VA-based for anything behind a firewall or requiring Windows APIs; SaaS Connectivity for pure-cloud targets with a public REST or SCIM endpoint. Many enterprises run both in the same ISC tenant — each source picks the connectivity model that fits its target.
The ISC config object representing one target system — holds credentials, schema (Account ID + Name), aggregation schedule, and provisioning settings. Default is read-only.
The technical bridge underneath a source — speaks the target's protocol (LDAP, SCIM, REST, JDBC). VA-based connectors run on your VA cluster; SaaS connectors run in SailPoint's cloud.
A lightweight Windows service installed on a Windows Server inside your network. Proxies Windows-only API calls (AD, Exchange, Skype) to the cloud ISC platform over TLS.
A BeanShell or criteria-based rule that maps an aggregated account to an identity cube — e.g. account.email == identity.email. No match = uncorrelated orphan.
A customer needs to connect ISC to an on-premises Oracle HR system behind a firewall. Which connectivity model should they use?
③ Account & group aggregation, schema, and IQService
Account aggregation is the process of pulling every account from a target system into ISC. A full aggregation reads all accounts; a delta aggregation reads only changes since the last run. You can trigger aggregation manually, on a schedule, or via the API. ISC stores the result as account objects keyed by Account ID.
Group aggregation reads the groups (or roles, entitlements, org units) from the target system so that ISC knows what groups exist before it can see which accounts are members of them. Groups become entitlements in ISC — the things you certify, request and revoke. Group aggregation must run before account aggregation completes membership data correctly.
IQService (also called the Integration Service) is a lightweight Windows service installed on a Windows Server inside your network. It acts as a proxy between ISC and systems that only expose Windows APIs — Active Directory, Exchange, Skype, RACF on Windows — giving the cloud platform access it could not get over standard protocols alone. A single IQService instance can serve multiple sources. SailPoint releases IQService updates regularly (the Feb-2025 and May-2025 releases added stability and TLS improvements). Always secure IQService with TLS and client authentication.
If you run account aggregation before group aggregation on an LDAP or AD source, membership attributes (memberOf) come in unresolved. Always schedule group aggregation first, or at minimum confirm groups are populated before you rely on entitlement data for certifications.
▶ Watch an AD account get aggregated, correlated and provisioned
End-to-end: source config fires an aggregation, the account is correlated to an identity, and a new entitlement is provisioned back to AD. Press Play for the healthy path, then Break it.
Why must group aggregation run before account aggregation finishes populating membership data?
④ Correlation rules — linking accounts to identities — and provisioning
After aggregation, ISC needs to decide which identity cube each account belongs to. That is the job of a correlation rule. A typical rule compares the account's email attribute against the identity's email attribute; if they match, the account is correlated. You can chain multiple criteria or use a custom BeanShell rule for complex cases.
When no match is found, ISC creates a uncorrelated account (sometimes called an orphan). Uncorrelated accounts should be reviewed regularly — they are a governance gap. Good schema design and a well-written correlation rule keep this number small.
Provisioning connectors
Once deep governance is enabled on a source, ISC can write changes back via the same connector. A provisioning plan is generated — listing the exact creates, modifies and deletes — and the connector executes it against the target. Provisioning can be direct (ISC to target) or queue-based (ISC to a service desk or manual-work-item queue). Always test provisioning in a sandbox source before enabling it on production.
Priya at a Pune NBFC faces this
After onboarding a new HR system source, 80% of the 4,000 aggregated accounts show as uncorrelated orphans in ISC even though every employee already has an identity.
The HR system stores email as 'priya.sharma@nbfc.co.in' but ISC identity cubes carry 'priya.sharma@nbfc.com' — a domain mismatch that makes the default email-match correlation rule fail.
Open Admin > Connections > Sources > [HR Source] > Correlation and check the rule criteria. Sample 5 orphan accounts and compare their email against the matched identity attribute — the domain suffix differs.
Admin ▸ Connections ▸ Sources ▸ HR Source ▸ CorrelationUpdate the correlation rule to strip the domain and compare only the local part (left of @), or add a transformation on the source attribute to normalise the domain before the rule runs. Re-run full aggregation.
After the next full aggregation, the uncorrelated account count should drop to near zero. Spot-check 10 previously orphaned accounts and confirm each is now linked to the correct identity cube.
Never trust a correlation rule until you have manually sampled at least 20 accounts across edge cases — contractors, service accounts, shared mailboxes. Run aggregation in test, inspect the identity cube links in ISC, and only then promote the rule to production.
After a full aggregation, the ISC admin notices a large number of uncorrelated accounts. What is the MOST likely root cause?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the difference between a VA-based connector and SaaS Connectivity, and when would you use each? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Source
- The ISC configuration object for one target system — holds credentials, account schema, aggregation settings and (when enabled) provisioning settings. Read-only by default.
- Connector
- The technical bridge beneath a source that speaks the target system's protocol — LDAP, SCIM, REST, JDBC, etc. VA-based or SaaS-hosted.
- Account aggregation
- The process of pulling all (full) or changed (delta) accounts from a target system into ISC as account objects.
- Correlation rule
- A BeanShell or criteria-based rule that maps an aggregated account to an identity cube — e.g. matching account.email to identity.email.
- Uncorrelated account
- An aggregated account ISC could not match to any existing identity cube — an orphan that represents a governance gap and should be reviewed.
- IQService
- A lightweight Windows service (also called Integration Service) that proxies Windows-only API calls between cloud-hosted ISC and on-prem Windows targets like AD and Exchange.
- SaaS Connectivity
- SailPoint's cloud-native connector framework for cloud-to-cloud integrations — connectors run in SailPoint infrastructure and need no VA.
- Provisioning plan
- The structured list of account creates, modifies and deletes generated by ISC when an access request or lifecycle event is approved — executed by the connector.
📚 Sources
- SailPoint — Identity Security Cloud Connectivity landing page. documentation.sailpoint.com/connectors/isc/landingpages/help/landingpages/isc_landing.html
- SailPoint — Configuring Sources in Identity Security Cloud. documentation.sailpoint.com/saas/help/sources/config_sources.html
- SailPoint — Introduction to IQService (Integration Service). documentation.sailpoint.com/connectors/iqservice/help/integrating_iqservice_admin/intro.html
- SailPoint — SaaS Connectivity developer documentation & SDK. developer.sailpoint.com/docs/connectivity/saas-connectivity/
- SailPoint — Aggregation Settings — account and group aggregation. documentation.sailpoint.com/connectors/saas/identity_security_cloud_gov/help/saas_connectivity/identity_security_cloud_governance/aggregation_settings.html
- SailPoint Developer Community — New Capability: Integration Service (IQService-May-2025) is now LIVE!. developer.sailpoint.com/discuss/t/new-capability-integration-service-iqservice-may-2025-is-now-live/103924
What's next?
Got sources and aggregation? Next, go deep on SailPoint access certification campaigns — how access reviews are launched, who gets included, what certifiers decide, and how automated remediation closes the loop on stale access.