IdentityAttribute Transforms not updating when LCS manually set

[gmilunich (Geoff Milunich)]

I am looking into using the option to manually set a lifecycle state on an identity to handle a situation (Pre-term). We have some fields that calculate based on the lifecycle state, and they do not appear to be being updated when the value is manually set. Is this intended? And how do I go about getting those calculated?

I found a similar topic, but there was no resolution for it:

Manually Setting LCS with Transform References

When manually setting the Lifecycle State, such as setting “Inactive”, IDN will perform the expected actions set on the Identity Profile (Disable/Enable). However, we have several Identity Attributes that reference the underlying “Lifecycle State” transform and thus their calculation would be out of sync with this setting. [image] For example setting the description as an Identity Attribute so we can utilize Attribute Sync: "lifecycleState": { "type": "reference", "attributes": { …

[ethompson (Edward Thompson)]

I am not aware of an API to identify what users were manually set, but here are some options I can see.

1. Set 2 Identity Attributes for LCS (1 is the regular cloutdLifecycleState, and another maps the Transform logic). Then you can see who differs between those 2 via Search.

2. Search for “Update Identity Attribute Value Passed” to find events where users were manually updated and then act upon that (Workflow/Script).

3. Create a loopback source that reads the Identity Attribute values. Get Users from /v3/search and correlate with their account then use the attributes.cloudLifecycleState from there as that will be the manually set value. This could be delayed as it would require an additional aggregation to run.

4. (Not recommended) Use the identityAttribute type of Transform to get the value of the attribute rather than the value of the referenced transform.

Note, there is an API that the Identity List page uses that has this info but it is not available:

/mice/v3/identities

Within that response is a manuallyUpdated flag (true/false)

[gmilunich (Geoff Milunich)]

I just tested this out again and it seems to be working for the situation that I was looking at, so this might not be an issue.

I can not say if it works for the linked topic or in all situation though.