I want to update the department value in Identity only if the start date for an account from the source is before today. If the account’s start date is in the future, I don’t want to update the existing department value.
Initially, I tried using ‘dateCompare’ and ‘static’ (using the source described below) to set the department in the Identity Profile. However, the department value was still updated even with a future start date.
I also tried using ‘nextProcessing’, but the result was the same when both Department and startDate were aggregated from the same source.
How can I preserve the existing department value?
{
"id": "xxxxxxx",
"name": "departmentUpdate",
"type": "dateCompare",
"attributes": {
"firstDate": {
"type": "dateFormat",
"attributes": {
"input": {
"type": "identityAttribute",
"attributes": {
"name": "startDate"
}
},
"inputFormat": "YYYY/MM/dd",
"outputFormat": "ISO8601"
}
},
"secondDate": {
"type": "dateFormat",
"attributes": {
"input": {
"type": "dateMath",
"attributes": {
"expression": "now"
}
},
"inputFormat": "yyyy-MM-dd'T'HH:mm",
"outputFormat": "ISO8601"
}
},
"operator": "lte",
"positiveCondition": {
"type": "accountAttribute",
"attributes": {
"sourceName": "xxxxxxx",
"attributeName": "department"
}
},
"negativeCondition": {
"type": "identityAttribute",
"attributes": {
"name": "department"
}
}
},
"internal": false
}
Hi @yukina_okamoto
Welcome to the Developer Community 
Here’s my current understanding — please let me know if it’s accurate:
- If
startDate is in the past → update the department value (but with which value exactly?).
I notice that the transform is returning the department from the identity attribute, which likely maps to the account attribute (assuming it’s defined in the identity profile).
- If
startDate is in the future → do nothing and retain the existing account attribute as the department value.
So essentially, my understanding is:
The transform always returns the department (from the account attribute) because there’s no logic implemented to generate or update a new department value.
Hi @yukina_okamoto,
Could you confirm which source is mapped to the ‘department’ attribute in your identity profile? Is it the same source referenced in the transform above?"
hello @yukina_okamoto, few questions - for a future dated hire, what should be the department value? For the ones whose department you want to update, is that value coming from a different source? can you explain the use case in detail if possible?
@sidharth_tarlapally , @aishwaryagoswami , @UjjwalJain
Thank you for confirming my questions.
My goal is to reflect data from the HR source in Identity only when a specific date in the aggregated data (like in example 2 below) is reached.
The original script mapped attributes with the same names in the Identity Profile.
If you have any ideas on how to modify the script and Identity Profile mapping, please share your insights.
*The date format is yyyy/MM/dd
- 2025/04/01 - Current data
[Account from HR Source]
“username” : yukina okamoto
“department” : Development department
“startDate” : 2025/04/01
[Identity]
“username” : yukina okamoto
“department” : Development department
“startDate” : 2025/04/01
2.2025/05/01 - ISC aggregation from the HR Source
[Account from HR Source]
“username” : yukina okamoto
“department” : Sales department
“startDate” : 2025/06/01
[Identity] *I don’t want to update the department and start date in Identity at this time.
“username” : yukina okamoto
“department” : Development department
“startDate” : 2025/04/01
- 2025/06/01 - Identity update from the HR Source
[Account from HR Source] *That data doesn’t change from 2.
“username” : yukina okamoto
“department” : Sales department
“startDate” : 2025/06/01
[Identity]
“username” : yukina okamoto
“department” : Sales department
“startDate” : 2025/06/01
(My English is not very strong, and I am relying on AI for assistance. Please excuse any mistakes or inappropriate phrasing.)
1 Like
For this scenario you require an identity attribute rule.
In the rule you have access to the existing identity attribute value and can safely return that value.
More information here: Identity Attribute Rule | SailPoint Developer Community
1 Like
HI @yukina_okamoto ,
When you say you don’t want to update “department” value when the “start date” is future, what value you want to update at this time? Will it be a blank value?
Let me come back with a transform
Hi @yukina_okamoto,
You can use a date comparison transform to compare the start date from HR with the current date. If the start date is in the future, you can retain the existing value of the attribute. Otherwise, you can map the value coming from HR.
Attached below is a sample transform:
{
“name”: “departmentUpdate”,
“type”: “dateCompare”,
“attributes”: {
“firstDate”: {
“type”: “dateFormat”,
“attributes”: {
“input”: {
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “HR Source”,
“attributeName”: “startDate”
}
},
“inputFormat”: “YYYY/MM/dd”,
“outputFormat”: “ISO8601”
}
},
“secondDate”: “now”,
“operator”: “lte”,
“positiveCondition”: {
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “HR Source”,
“attributeName”: “department”
}
},
“negativeCondition”: “$oldValue”
},
“internal”: false
}
Thank you for all your help and advice.
If you have any alternative solutions besides using cloud rules(I’ll check it), please share your ideas.
@oliver_goebel2
Thank you, I understand that if I need to use cloud rules, I should seek support from a SailPoint expert. I will discuss this with our contact team.
@JackSparrow
Thank you for the confirmation. If the start date hasn’t been reached, I want to maintain the existing value as shown in the replay
@UjjwalJain
Thank you for sharing your idea. I tried implementing it by setting the Identity Profile, but I couldn’t achieve the desired result..
Hi @yukina_okamoto,
Are you seeing any errors or unexpected results ?
@UjjwalJain
I didn’t receive any errors. However, the script still returned the new department value even if the start date is in the future.
It seems that the $oldValue variable isn’t working as expected.
Hi @yukina_okamoto ,
$oldValue returns the previous value before the update. To properly test this, let’s first simulate a real scenario where the startdate is less than or equal to the current date. In this case, the department value should be updated.
Initial Test (Start Date ≤ Current Date):
HR Source:
- startdate: 2025/05/15
- department: Dept 1
Identity:
Now, update the same user in the HR source by setting the startdate to a future date and changing the department value. Then, trigger the aggregation.
Future Start Date Test:
HR Source:
- startdate: 2025/05/17
- department: Dept 2
Identity:
In this case, the identity system should retain the previous department value (Dept 1) from the real scenario, since the new start date is in the future.
1 Like
Thank you for reviewing my scenario. Your understanding is excellent.
After the ‘Future Start Date Test’, I expect Identity to update to Dept2 when the data reaches ‘2025/05/17’.
Thanks for confirming, @yukina_okamoto.
Could you please try using the transform I provided above?
Thank you following, @UjjwalJain ,I share my test result.
I tested the provided transform by applying it to the department column.
Initial Test (Start Date ≤ Current Date): OK
HR Source:
- startdate: 2025/05/15
- department: Dept 1
Identity:
- startdate: 2025/05/15 *
- department: Dept 1
Future Start Date Test: NG
HR Source:
- startdate: 2025/06/01
- department: Dept 2
Identity:
- startdate: 2025/06/01 *
- department: Dept 2
→ I was unable to preserve the previous value…
*Reference: Identtiy startDate column is simple mapping (HR Source startdate = Identity startdate)
Hi @yukina_okamoto,
Just to clarify, are you using “YYYY/MM/dd” or “yyyy/MM/dd” ?
If you’re using “YYYY/MM/dd” , could you please update it to “yyyy/MM/dd” ? Apologies for the confusion—I mistakenly used “YYYY/MM/dd” in the sample transform above.
With this minor change, it’s working on my end. Please test it the same way I suggested earlier and let me know if you run into any issues.
2 Likes
Thank you , My transform is working!
I appreciate the support from @UjjwalJain and the other support members.
Could you provide further guidance? If we want to achieve the same result for attributes other than the department attribute, would we need to create a separate transform for each attribute?
1 Like
Hi @yukina_okamoto,
Creating separate transforms for each attribute sounds like a great approach.
1 Like