Onboarding Applications into SailPoint
One key insight I’ve gained from onboarding applications into SailPoint is that selecting the appropriate connector is a critical decision made early in any integration project. The choice of connector impacts every downstream process—from data aggregation and correlation to provisioning and auditing. Choosing the right connector upfront can make the entire integration smoother and more manageable.
My approach to connector selection follows a clear and pragmatic strategy:
Out-of-the-box Connectors: When SailPoint offers a native connector for an application—such as ServiceNow, Workday, Azure AD, or SAP—I always default to using it. These connectors are extensively tested, regularly maintained for compatibility with application updates, and come with predictable, enterprise-grade behavior. This reliability is crucial during audits and troubleshooting since the connector’s performance and compliance are well-documented and supported by the vendor.
JDBC or LDAP Connectors for Database or Directory-backed Apps: For applications supported by a backend database or LDAP directory, I typically prefer JDBC or LDAP connectors. These connectors excel when the underlying schema is stable and the data volume is substantial. They allow for efficient, direct access to identity information and attributes with minimal overhead. However, care must be taken to understand the schema intricacies and ensure consistency since schema changes in databases or directories can cause integration interruptions.
Custom REST Connectors for API-based Applications: If neither out-of-the-box nor database/LDAP connectors are viable options, but the application exposes REST or SCIM APIs, building a custom REST connector is often the best route. Modern RESTful APIs provide significant flexibility, including fine-grained control over data retrieval, secure authentication mechanisms like OAuth2, and built-in support for token management and throttling. This allows for scalable, secure integrations that are adaptable to evolving API versions and security policies.
The decision on which connector to use hinges on several key practical factors:
The authentication mechanism supported by the application—whether OAuth, Kerberos, Basic Authentication, or custom header tokens has direct implications on connector security and session management.
The complexity and structure of the application’s data model, which affects schema mapping and the accuracy of identity correlations.
API limitations such as throttling thresholds and paging requirements that influence performance and error handling strategies.
Organizational security expectations around data transmission, encryption, and audit trails.
The anticipated operational burden, including the level of ongoing maintenance, updates, and troubleshooting that the internal team can realistically support.
Once the connector type is finalized, my process includes detailed schema mapping from source attributes to SailPoint identity fields, multiple rounds of test aggregations to verify data accuracy and completeness, and rigorous validation of identity correlation rules to ensure that downstream access management policies are enforced correctly. Finally, comprehensive documentation is created so that Operations teams have clear guidance and context for long-term management, monitoring, and troubleshooting.
While connector selection might seem like a straightforward step, it is arguably one of the most crucial decisions you will make in any SailPoint integration. Getting it right upfront lays the foundation for a smooth, efficient, and sustainable identity integration process.