How do you handle identity state mismatch between SailPoint ISC and target systems during provisioning?

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

Hi everyone,

I’ve been thinking about scenarios where there is a mismatch between SailPoint ISC and the target system state during provisioning.

For example:

  • ISC provisions an account update (like DN change, role assignment, or status update)
  • The target system successfully applies the change
  • But ISC is not immediately aware of the updated state until the next aggregation

This creates a temporary inconsistency where:

  • Provisioning is successful
  • But ISC still reflects outdated data

What I’ve Observed:

From some scenarios:

  • DN changes in AD are not reflected until aggregation

  • Role or entitlement updates done externally are not visible immediately

  • Provisioning plans may fail partially if ISC relies on stale dataPossible Approaches (Based on my understanding):

    • Trigger aggregation (full or single account) after critical changes
    • Use APIs or workflows to sync state post-provisioning
    • Design provisioning in a way that minimizes dependency on immediate state refresh
    • Accept eventual consistency and design processes around it

    My Question:

    How do you usually handle this “state mismatch” problem in real implementations?

    • Do you rely on aggregation?
    • Do you trigger any post-provisioning sync mechanism?
    • Or do you design around eventual consistency?

    Would love to hear how others approach this in production environments.

    Thanks!

2

Hi @miteshpatidar Welcome to the Dev Community!

Best way to “handle” this? Not to worry about it :wink:

What I mean is; just change the way you think about it.

Provisioning and Aggregation are 2 separate areas of funtionality. ISC is an Aggregation engine (for governance) purposes with additional Provisioning functionality. Do not think of SailPoint ISC simply as a Provisioning engine.

BTW, DN is a special case, see Best Practices: Active Directory Account Moves - Compass

3

Hi Mitesh,

Welcome to the SailPoint Developer Community!

This is a really good point — I’ve seen this kind of mismatch quite often, especially with systems like AD where changes (like DN updates) are not immediately reflected back in ISC.

In practice, we’ve mostly treated this as an eventual consistency scenario. Aggregation helps bring things back in sync, but relying on it for every change doesn’t always scale well.

For more critical cases, a targeted or single account aggregation can help reduce the gap, but for the most part, designing provisioning flows in a way that doesn’t depend on immediate state updates has worked better.

So it’s usually a mix of:

  • accepting some delay (eventual consistency)
  • using aggregation where needed
  • and avoiding dependencies on refreshed attributes during the same flow

Thanks for raising this!

4

@Gxurav713 I see you are still generating AI slop

5

Hi @PhilRawlings1

I do use AI sometimes to help frame or structure my replies better.

But the understanding and thoughts are usually based on my own learning and experience first. I’m mainly using it to improve wording and make the response more readable — not to blindly generate answers.

Still learning and trying to contribute meaningfully to the community.

6

Hi @Gxurav713

Could you maybe give more detail on where you have seen this mismatch “quite often” and the issues experienced (apart from DN, which, as we all know, is a special case)?

I ask, because I haven’t experienced it myself.