Just using a transform or identity attribute rule, I don’t think it’s possible!
You can always create a Delimited File source to achieve this — I don’t recommend it, but it is achievable.
For example:
Create a Delimited File source that will track accounts that have gone through valid cost center changes.
Include at least two account attributes:
userId (used for correlation)
costCenterChangeDate (to store the date of the change)
Create a workflow that will be triggered when the cost center changes.
Check if it’s a valid change (e.g., let’s say in your leaver process the cost center becomes empty — in that case, just do nothing).
In your workflow, use the variable $.now() to get the current timestamp.
Create or update the record in the Delimited File source (via Http Request) by passing the userId and costCenterChangeDate.
In your Identity Profile, create an attribute that points to this source (e.g., via an account attribute mapping or transform) to pull in the date information.
You can do this in a single static transform (pseudo):
latestCostCentre = Get auth account’s cost center code.
knownCostCentre = Get last known cost center code from one of the downstream systems’ account.
currentCostCentreChangeDate = Get identity’s current/recorded cost centre change date.
today = today’s date
Here, the only usage of the identity attribute reference is on the change date attribute itself, so this current thread would not be in any conflict with other identity attribute processing threads.
Assuming cost center is synced to one of the downstream system, so on there, there’s the historical / last known cost centre that you can read from, and it would not conflict with the cost center attribute processing thread either.
That transform would only work if the Cost Center identity attribute hasn’t already been updated. Once the Cost Center identity attribute is updated, the date will be change to the current date.
So whenever an identity refresh occurs, the changed date identity attribute will be updated to the current date.
Just to add one more suggestion to the thread. Do you actually need the change date to be an identity attribute, or do you just need to be able to search for the date someone’s Cost Center changed? I only mention it because if you are just looking to search for when the cost center of someone changed, you could turn on native change detection for your source for that attribute and search the ISC events for the changes using something like the below search query. It can be further scoped to a specific Target/Identity/Source/etc..
name:"Update Native Change Detected" AND attributes.singleValueAttributeChanges:"*costCenter*"
This might not be what you are looking for, but I figured I would through it out there as a simple answer in case it does help your use case.