How to prevent sudden source changes

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hey All,

Just wanted to check if there is any way similar to account deletion threshold under source configuration for aggregation to prevent bulk/sudden changes to number of active or inactive accounts?

Kind regards,

Aayush

2 Likes
2

No we don’t have that option in SailPoint ISC. you can subscribe notification via workflow but you can’t cancel

3

Yes, we don’t have any OOTB option. But see if you can play around native change detection option using workflows.

4

Hey

sure will check the same.

5

@AsGoyal In SailPoint Identity Security Cloud (ISC), there is no out-of-the-box (OOTB) “circuit breaker” specifically for bulk changes to account status (Active/Inactive) similar to the Account Deletion Threshold

You can use the given best practices:

  1. Native Change Detection (Workflow)
    You can build a SailPoint Workflow to act as a monitoring layer:
    Trigger: Use the Aggregation Completed trigger.
    Action: Use an HTTP Request or Search step to count the number of identities whose lifecycle state or account status changed during that window.
    Safety: While this cannot automatically “stop” the aggregation that already finished, it can trigger an immediate alert or a second workflow to “disable” subsequent provisioning to downstream systems if a certain percentage is exceeded.

  2. Identity Profile “Lifecycle State” Safeguards
    Since status changes usually trigger lifecycle transitions (e.g., Active to Inactive), you can add a safety buffer at the identity level:
    Separate States: Create an “Intermediate Inactive” state that holds users for a period (e.g., 24-48 hours) before revoking access.
    Notifications: Configure the transition to this state to email the IGA team if the bulk change was unintentional.

  3. Source Filtering (Connector Level)
    If you are using a Direct Connect source (like Active Directory or a JDBC source), you can apply Aggregation Filters to exclude specific OUs or status values. This prevents ISC from even “seeing” the changed records, effectively freezing their current state in the system until you verify the source data.

6

Thank All,

I will check the approach.