Note: This article focuses on selecting the appropriate connectivity method for creating an ISC source. It does not cover SailPoint’s Application Onboarding capability.
Problem
During application onboarding in SailPoint Identity Security Cloud (ISC), teams often jump straight into connector configuration, frequently defaulting to a Web Services connector, without first evaluating whether a simpler or better-supported integration method is available.
This leads to unnecessary complexity: more custom API mapping, more configuration to maintain, and a higher effort and timeline than the application actually required.
Diagnosis
The root cause is the lack of a structured evaluation step before implementation begins. ISC supports multiple integration methods, including Out-of-the-Box (Direct) Connectors, SCIM, Web Services, JDBC, and Delimited File connectors, each suited to different application capabilities.
Without first checking what the target application actually supports (a native SailPoint connector, SCIM 2.0, REST APIs, database access, or file exports), teams risk choosing a heavier integration method than necessary, increasing both implementation effort and long-term maintenance.
Solution
Evaluate the application’s integration capabilities before selecting a connector, using the following structured approach.
Questions to answer first:
- Does SailPoint provide a supported Out-of-the-Box connector?
- Does the application support the SCIM 2.0 standard?
- Does it expose REST APIs for account and entitlement management?
- Is user information stored in a relational database?
- Is provisioning required, or is the integration only for account aggregation?
- What authentication methods are supported (OAuth, API Keys, Basic Authentication, etc.)?
Recommended evaluation order:
- Out-of-the-Box (Direct) Connector - Check first whether SailPoint provides a supported connector (e.g., Microsoft Entra ID, Workday). These are supported by SailPoint, require less configuration, and are easier to maintain long-term.
- SCIM Connector - If no Out-of-the-Box connector exists, check whether the application supports SCIM 2.0. Standardized APIs mean less customization than a generic REST integration. Best suited for modern SaaS applications.
- Web Services Connector - If SCIM isn’t supported but the application exposes REST APIs, this is usually the right choice. It offers flexibility for custom or unsupported applications, but requires a solid understanding of the API’s documentation, authentication, request/response structure, and pagination.
- JDBC Connector - If the application stores identity data in a relational database, and direct database access is permitted by architecture and security policy, this connector can aggregate (and in some cases provision) directly against the database.
- Delimited File Connector - When no online integration interface is available, file-based integration (CSV or similar, via scheduled batch exchange) is the fallback. Less automation, but effective for legacy systems.
Comparison at a glance:
| Integration Method | Typical Scenario | Advantages | Considerations |
|---|---|---|---|
| Out-of-the-Box Connector | Supported enterprise applications | Certified, supported, minimal configuration | Limited to supported applications |
| SCIM Connector | SCIM-compliant applications | Standards-based, reduced customization | Requires SCIM implementation by the application |
| Web Services Connector | REST API integrations | Highly flexible | Requires API analysis and configuration |
| JDBC Connector | Database-backed applications | Direct database integration | Requires database connectivity and appropriate access |
| Delimited File Connector | File-based integrations | Simple implementation for batch processing | Not suitable for real-time integrations |
Decision flow:
- Check for a supported Out-of-the-Box connector.
- If none, check for SCIM support.
- If no SCIM, check for REST APIs.
- If no REST APIs, check for relational database access.
- If database access isn’t possible, fall back to Delimited File integration.
Best practices:
- Always evaluate supported Out-of-the-Box connectors before considering custom integrations.
- Review the application’s integration documentation before designing the solution.
- Confirm whether the integration requires aggregation only, or both aggregation and provisioning.
- Validate authentication methods and API capabilities early in the onboarding process.
- Consider long-term maintainability and supportability when selecting an integration method.
- Document the rationale for the selected integration approach as part of the onboarding design.
There’s no single integration method that fits every application. The optimal choice depends on the application’s capabilities, business requirements, and operational considerations. Following this evaluation process before jumping into configuration helps select the integration method that best balances functionality, maintainability, and long-term support, setting a strong foundation for the onboarding project.