Unexpected Account Creates and Deletes During Optimized Aggregations

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

Hi All,

Just to provide some context, we have a trusted source configured and are currently running optimized aggregations (execute via API).

We have observed that even when there are only one or two record changes in the source data, a full aggregation reports a significant number of accounts as deleted and re-added in the aggregation summary. For example:

  • Accounts Created: 23,553
  • Accounts Deleted: 15,000
  • Accounts Scanned: 96,000

Given the minimal changes in the source data, these results seem unexpected.

We’re trying to understand what might be causing this behaviour. Is it recommended to perform a non-optimized aggregation at least once before switching to optimized aggregations, or could there be another factor contributing to these results?

Any insights or guidance would be greatly appreciated.

Thanks.

2

Hi,

Yes, it’s generally a good practice to run at least one full (non-optimized) aggregation after initial source configuration or after significant source changes before relying on optimized aggregations.

In SailPoint Identity Security Cloud, large numbers of accounts being deleted and re-created despite minimal source changes can indicate:

  • Changes to the account schema or aggregation configuration
  • A change in the account’s unique identifier/native identity
  • Issues with the source’s change-tracking mechanism used by optimized aggregation
  • The optimized aggregation baseline becoming out of sync

I’d recommend:

  1. Run a full aggregation and review the results.
  2. Verify that the account ID/native identity has remained stable.
  3. Check whether any source configuration, schema, or correlation attributes changed recently.
  4. Compare a few sample accounts that appear in both the “deleted” and “created” counts to see whether ISC is treating them as entirely new accounts.

If the behavior persists after a full aggregation, it may be worth opening a SailPoint support case, as the change-detection logic may not be receiving consistent data from the source.

3

Hi @lalithajay ,

One possible cause is that ISC is not able to match the incoming accounts with the existing accounts during aggregation. This can happen if the account ID/native identity has changed or is being returned inconsistently by the source. In such cases, ISC may treat accounts as deleted and then create them again.

It’s generally a good idea to run a full (non-optimized) aggregation at least once to establish a baseline before relying on optimized aggregations. I’d also recommend checking whether there have been any recent changes to the schema, correlation logic, or account identifiers being returned by the source.

Given that only a few records changed in the source, the large number of deletions and creations suggests there may be an account matching issue rather than actual account changes.

Thanks.

4

Thanks for the direction, yes, we are planning to further explore the incoming data and few points you stated

5

Thanks for your reply,

Yes after further checks it is all due to inconsistent records sent by the source.

There is a pagination involved and had to change the SQL query behind to send consistent data across pagination