Hi,
I sometimes see the “Identity Attribute Change” in Identity/Access History for some accounts coming from an authoritative source, which shows that the attributes have been updated from none → new values from source.
For the mojority of the accounts there is no such step.
Because we have a workflow with attribute change trigger, the workflow will be called in such case. But this is not a really change, only none-> new value.
I guess ISC creates empty identity and updates later, instead of creating with the values.
Do you know, why does this happen?
Second question: This Identity Attribute Change from none->value from source is not written in “events” though. I can see this step only in Access History not in events via search. Is there a possibility to see this changes in events too?
Hi @onbir
From what I’ve seen with that trigger, that’s completely normal behavior. The only exception is that the cloudLifecyclestate attribute is not included in this null → newstatus.
In my opinion, that’s technically an attribute change, so it should be included. If you want to filter out those results, you can add a JSON Path filter, something like this:
$.changes[?(@.oldValue != null)]
OR
you can also add a compare strings step at the start of your workflow that closes out the workflow execution if it sees the oldValue as null.
Unfortunately no, not what from what I’ve seen. In my opinion, I think the events tab is already populated heavily with tons of information, if we also had identity attribute changes in there, it would be a ton of noise. I have had clients that have over 100+ identity attributes, so a single identity refresh could trigger thousands of events.
Thank you @trettkowski ,
we unfortunately have the cloudLifecycleState in this Identity Attribute Change step too:
This doesn’t happen in Sandbox, only in PROD. In Sandbox the account will be created with source values directly, no update afterward. I can’t find any explanation for that.
I see. I would like to get this information via API and analyse locally, how often it occurs.
Yeah, I would expect to see cloudLifecycleState in the access history, but in the attribute change trigger, it specifically states that it won’t fire for cloudLifecycleState changes from null → active. Doc reference:
This event trigger doesn’t detect an identity’s change in lifecycle state from ‘null’ to ‘active’, so it’s recommended that you set an identity’s lifecycle state when it’s created. You can then use the Identity Created trigger to detect that change to ‘active’ for Joiners.
That seems like a bug in your Sandbox environment. The correct behavior is what you’re seeing in production.
You can get that from the API docs below. The eventType is “AttributesChanged” .