Building a Failsafe Identity Validation Layer in SailPoint ISC

Problem

Identity data entering SailPoint Identity Security Cloud (ISC) from authoritative sources like SAP SuccessFactors is often incomplete, outdated, or inconsistent. This includes missing key attributes such as employee ID, manager reference, office location, or email address. If these malformed identities are allowed to progress through SailPoint’s lifecycle states unchecked, they can lead to provisioning failures, incorrect access grants, and audit violations.

While SailPoint offers transforms, rules, and workflows to manipulate and inspect data, applying complex validation logic across many identities and multiple authoritative sources quickly becomes unmanageable. Teams often end up duplicating logic across various transforms or identity profiles, increasing technical debt and making the solution fragile and difficult to scale. What’s missing is a centralized validation layer where all identity data—regardless of source—can be uniformly enforced according to organizational data quality standards.

Ideally, validation rules should be implemented directly within SAP SuccessFactors, the source of truth for HR data. However, this is often outside the control of the IAM team. Instead, IAM teams are left to deal with the downstream repercussions of bad data—fixing access issues, fielding support tickets, and manually remediating identity records. In this context, SailPoint can serve as a critical gatekeeper, sitting between the authoritative source and downstream systems. The proposed solution introduces a failsafe mechanism that enforces data integrity before an identity is allowed to activate or provision, helping organizations avoid the consequences of unchecked identity corruption.

Unfortunately, SailPoint does not currently support a hook into the SAP SuccessFactors connector via any rule, transform, or customizer. This limitation—confirmed by SailPoint support and validated through hands-on testing—prevents inline validation at the point of aggregation. As a result, teams must implement validation logic after aggregation completes, requiring alternative approaches to intercept and quarantine bad data before it activates downstream provisioning.

Diagnosis

In our implementation, we observed several identities being ingested from SAP SuccessFactors with incomplete or malformed data. These missing attributes—like manager, email, or employee type—caused downstream failures during account provisioning and access reviews, creating operational overhead.

Since SailPoint ISC does not support inline validation during aggregation from SuccessFactors, and since we confirmed no rule hooks are available on the connector, we needed an alternative way to enforce data integrity after aggregation but before the identities could activate and provision downstream.

Solution

Given the confirmed limitation that SailPoint ISC does not support hooks into the SAP SuccessFactors connector—via rules, transforms, or any other customizable extension—we developed a post-aggregation data sanitization process to validate and control identity progression using native extensibility features.

Here’s how the solution works:

  • Triggered by Event: The Python-based function is invoked via a SailPoint event trigger or workflow that listens for the “account aggregation completed” event. This ensures the validation logic runs immediately after data is ingested from SAP SuccessFactors.
  • Attribute Validation: The function queries the /identities API to retrieve newly aggregated records and evaluates each identity for completeness. Validation checks include critical attributes such as employeeId, email, manager, agency, location, and employeeType.
  • Breaker Status Writeback: Identities that fail validation are written to a custom source in ISC (e.g., IAM-DataSanitization) using the /accounts API. The record includes the employeeId, a breaker_status of dirty or clean, and a detailed reason explaining the failure.
  • Lifecycle Enforcement: A transform or rule in ISC inspects the custom sources’ account’s breaker_status. If set to dirty, the identity is transitioned into a ForReview lifecycle state. This halts downstream provisioning and flags the user for manual remediation.
  • Automated Reporting & Notification: A CSV report of all dirty identities is generated and sent via email to a designated distribution list, such as IAM admins or HR data stewards, so corrective actions can be taken in the source system.

This event-driven solution enforces a strong identity validation gate after aggregation but before activation, filling the gap left by the current limitations of the SuccessFactors connector and enabling clean, auditable identity onboarding.

4 Likes

Have you considered submitting this to the CoLab Marketplace?

SailPoint Developer Community