testipona
(Troy Estipona)
May 22, 2026, 11:55am
1
Hi everyone,
I’m currently working on a transform and running into an issue where the expected value is not being generated.
Use Case:
I want to populate a timestamp (current time + 2 hours) when cloudLifecycleState contains manualinactive. Otherwise, it should fall back to an existing attribute.
{
“name”: “Determine LCS Transition Preterm Timestamp”,
“type”: “firstValid”,
“attributes”: {
“values”: [
{
“type”: “conditional”,
“attributes”: {
“expression”: “$lcs != null && $lcs.toLowerCase().contains(‘manualinactive’)”,
“lcs”: {
“type”: “identityAttribute”,
“attributes”: {
“name”: “cloudLifecycleState”
}
},
“positiveCondition”: {
“type”: “dateFormat”,
“attributes”: {
“input”: {
“type”: “dateMath”,
“attributes”: {
“expression”: “now+2h”
}
},
“outputFormat”: “yyyy-MM-dd’T’HH:mm:ss”
}
},
“negativeCondition”: {
“type”: “static”,
“attributes”: {
“value”: null
}
}
}
},
{
“type”: “identityAttribute”,
“attributes”: {
“name”: “lcsMovePretermTimestamp”
}
}
]
},
“internal”: false
}
Issue
The transform is returning an empty value instead of the expected formatted timestamp when cloudLifecycleState contains manualinactive.
Any guidance or suggestions would be greatly appreciated. Thanks in advance!
j_place
(Jeremy Place)
May 22, 2026, 12:18pm
2
Hi @testipona FWIK, eq is the only operator available for a conditional expression. See Conditional | SailPoint Developer Community
Maybe consider a static transform with velocity template logic.
kannan_sb85
(Kannan Sriniyappan Balakrishnan)
May 22, 2026, 12:58pm
3
@testipona Troy, I think the issue with the transform code - To address the identified issues, the transform needs to be restructured. The primary change involves how the cloudLifecycleState is evaluated and how the dateMath output is handled before dateFormat.
{
"id": "7ea7c617-2876-4893-b2e9-7d22c0e797d1",
"name": "Determine LCS Transition Preterm Timestamp",
"type": "firstValid",
"attributes": {
"values": [
{
"type": "conditional",
"attributes": {
"expression": "$normalizedLcs eq manualinactive",
"normalizedLcs": {
"type": "static",
"attributes": {
"value": "$lcs.toLowerCase()",
"lcs": {
"type": "identityAttribute",
"attributes": {
"name": "cloudLifecycleState"
}
}
}
},
"positiveCondition": {
"type": "dateFormat",
"attributes": {
"input": {
"type": "dateMath",
"attributes": {
"expression": "now+2h"
}
},
"outputFormat": "yyyy-MM-dd'T'HH:mm:ss"
}
},
"negativeCondition": {
"type": "static",
"attributes": {
"value": null
}
}
}
},
{
"type": "identityAttribute",
"attributes": {
"name": "lcsMovePretermTimestamp"
}
}
]
},
"internal": false
}
Try this code, it should work I tested in my tenant.
Regards,
Kannan
testipona
(Troy Estipona)
May 22, 2026, 3:14pm
4
HI @kannan_sb85 ,
I tried to apply this transform and lcsMovePreTermTimestamp attribute still null value.
e.g. End Date is 05/23/2026 23:30:00. the expected value must be 05/24/2026 01:30:000.
testipona
(Troy Estipona)
May 22, 2026, 3:34pm
5
This is the mapping that we had on our identity profile (We have two profiles: Workday and Beeline) in which we use the transform.
j_place
(Jeremy Place)
May 22, 2026, 3:40pm
6
Hi @testipona I appreciate this isn’t answering the question, but won’t this attribute get re-calculated for every Identity refresh? Is that what you are after?
testipona
(Troy Estipona)
May 22, 2026, 3:45pm
7
Hi @j_place ,
Yes, that’s what we are aiming for.
if the value already exist, reuse the value.
then if we change lcs to manualinactive, we will set a new timestamp.
kannan_sb85
(Kannan Sriniyappan Balakrishnan)
May 22, 2026, 5:02pm
9
@testipona - Looks strange can you try this updated code
{
"id": "7ea7c617-2876-4893-b2e9-7d22c0e797d1",
"name": "Determine LCS Transition Preterm Timestamp",
"type": "firstValid",
"attributes": {
"values": [
{
"type": "identityAttribute",
"attributes": {
"name": "lcsMovePretermTimestamp"
}
},
{
"type": "static",
"attributes": {
"lcs": {
"type": "identityAttribute",
"attributes": {
"name": "cloudLifecycleState"
}
},
"pretermDate": {
"type": "firstValid",
"attributes": {
"values": [
{
"type": "dateFormat",
"attributes": {
"inputFormat": "ISO8601",
"outputFormat": "MM/dd/yyyy HH:mm:ss",
"input": {
"type": "dateMath",
"attributes": {
"expression": "+2h",
"input": {
"type": "dateFormat",
"attributes": {
"inputFormat": "MM/dd/yyyy HH:mm:ss",
"outputFormat": "ISO8601",
"input": {
"type": "identityAttribute",
"attributes": {
"name": "endDate"
}
}
}
}
}
}
}
},
{
"type": "dateFormat",
"attributes": {
"inputFormat": "ISO8601",
"outputFormat": "MM/dd/yyyy HH:mm:ss",
"input": {
"type": "dateMath",
"attributes": {
"expression": "now+2h"
}
}
}
}
]
}
},
"value": "#if($lcs && $lcs.toLowerCase().contains(\"manualinactive\"))$pretermDate#end"
}
}
]
},
"internal": false
}
Regards,
Kannan
testipona
(Troy Estipona)
May 25, 2026, 2:26pm
10
Hi @kannan_sb85 ,
I update the transform. still the lcdmovepretermtimestamp from the preview still has no value.
testipona
(Troy Estipona)
May 26, 2026, 9:05am
11
Hi @kannan_sb85 ,
This transform works now with our tenant. There’s been a confusion on our data that makes pretermtimestamp attribute no value.
Appreciate this help! Thanks a lot!
testipona
(Troy Estipona)
May 26, 2026, 1:27pm
12
Hi @kannan_sb85 ,
Instead of pivoting the value of the lcsmovepretermtimestamp to endDate, how can we pivot it to current time + 2 hours?
e.g. we change the lcs from active to manualinactive and the date/time now is May 26, 2026 22:00:00, assuming that the account has no endDate or it has endDate value, can we instead pivot it to current time which will gave us May 27, 2026 00:00:00?
kannan_sb85
(Kannan Sriniyappan Balakrishnan)
May 26, 2026, 3:43pm
13
Troy, the simple change in the transform code will helps → Drop endDate Entirely, always Use now+2h. Since you want the timestamp to always anchor to the current time (regardless of endDate), the pretermDate variable becomes a straightforward two-step chain: dateMath(now+2h) → dateFormat. No firstValid needed inside it anymore.
{
"id": "7ea7c617-2876-4893-b2e9-7d22c0e797d1",
"name": "Determine LCS Transition Preterm Timestamp",
"type": "firstValid",
"attributes": {
"values": [
{
"type": "identityAttribute",
"attributes": {
"name": "lcsMovePretermTimestamp"
}
},
{
"type": "static",
"attributes": {
"lcs": {
"type": "identityAttribute",
"attributes": {
"name": "cloudLifecycleState"
}
},
"pretermDate": {
"type": "dateFormat",
"attributes": {
"inputFormat": "ISO8601",
"outputFormat": "MM/dd/yyyy HH:mm:ss",
"input": {
"type": "dateMath",
"attributes": {
"expression": "now+2h"
}
}
}
},
"value": "#if($lcs && $lcs.toLowerCase().contains(\"manualinactive\"))$pretermDate#end"
}
}
]
},
"internal": false
}
One thing to confirm: If ISC dateMath operates in UTC . If your tenant or the consuming system expects local timezone, you may need a dateTimeZone + dateFormat step added after the dateMath to shift to the correct zone before formatting.
Try this out and let me know, is that works for you.
Regards,
Kannan