Hi Team,
We are trying to terminate AD users in the correct local timezone but it is not working for IST timezone users and we are using lookup table tranform for user locations and timezone offset.
Thanks
Kalyan
Hey @kalyannambi2010!
The solution here is going to be very dependent on the sources you have in place and how your cloudLifecycleState identity attribute is populated/how you’re determining whether/when to terminate accounts.
As an example, if you’re using Workday as your authoritative source, it’s possible to map (on the Workday side) a user’s location’s UTC offset to a calculated field, which you would then pull into IdentityNow. You could then leverage that attribute in a Date Math transform (nested inside a Date Compare transform, nested inside other transforms) to determine whether the cloudLifecycleState should be changed to Terminated or whatever you call it in your environment.
Different setups would have different solutions, so we’ll need to know more about your use case.
Hi @sup3rmark,
Thank you for your reply. We are using below transform and for locations “Hyderabad (SEZ)” and “Bangalore (Non-SEZ)” looks like transform not updating accordingly.
{
“id”: “xxxx-88d7-4749-9b38-yyyy”,
“name”: “Transform_EmpStatus_C”,
“type”: “replace”,
“attributes”: {
“regex”: " ",
“replacement”: “”,
“input”: {
“type”: “lower”,
“attributes”: {
“input”: {
“type”: “firstValid”,
“attributes”: {
“values”: [
{
“type”: “dateCompare”,
“attributes”: {
“firstDate”: {
“type”: “dateMath”,
“attributes”: {
“expression”: “+17h”,
“input”: {
“type”: “dateFormat”,
“attributes”: {
“input”: {
“type”: “firstValid”,
“attributes”: {
“values”: [
{
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday”,
“attributeName”: “TERMINATION_DATE”
}
},
{
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday”,
“attributeName”: “CONTRACT_END_DATE”
}
}
]
}
},
“inputFormat”: “MM/dd/yyyy”,
“outputFormat”: “ISO8601”
}
}
}
},
“secondDate”: {
“type”: “dateMath”,
“attributes”: {
“input”: “”,
“expression”: {
“attributes”: {
“values”: [
“now”,
{
“attributes”: {
“userTimeZoneOffset”: {
“attributes”: {
“input”: {
“type”: “static”,
“attributes”: {
“value”: {
“type”: “replaceAll”,
“attributes”: {
“table”: {
“\s*”: “”
},
“input”: {
“type”: “lower”,
“attributes”: {
“input”: {
“type”: “substring”,
“attributes”: {
“begin”: -1,
“end”: {
“type”: “lastIndexOf”,
“attributes”: {
“substring”: “(”
}
},
“input”: {
“type”: “accountAttribute”,
“attributes”: {
“attributeName”: “LOCATION”,
“sourceName”: “Workday”
}
}
}
}
}
}
}
}
}
},
“table”: {
“seattle”: “-480”,
“sanjose”: “-480”,
“jakarta”: “+420”,
“field-ga”: “-300”,
“hyderabad”: “+330”,
“bangalore”: “+330”,
“paris”: “+60”,
“boulder”: “-360”,
“riyadh”: “+180”,
“f5tower”: “-480”,
“billerica”: “-240”,
“mumbai”: “+330”,
“chertsey”: “+60”,
“field-wa”: “-480”,
“uaehomebase”: “+240”,
“field-il”: “-300”,
“ukhomebase”: “+60”,
“field-nh”: “-300”,
“libertylake”: “-480”,
“field-nj”: “-300”,
“field-ca”: “-480”,
“field-fl”: “-300”,
“field-ky”: “-300”,
“field-tx”: “-300”,
“london”: “+0”,
“britishcolumbia”: “-420”,
“field-va”: “-300”,
“luxembourghomebase”: “+60”,
“cork”: “+60”,
“noida”: “+330”,
“saudiarabiahomebase”: “+180”,
“chertseycampus”: “+60”,
“dubai”: “+240”,
“istanbul”: “+180”,
“field-nc”: “-300”,
“sanfrancisco”: “-480”,
“newdelhi”: “+330”,
“singaporeoffice”: “+480”,
“field-ma”: “-300”,
“mexicohomebase”: “-300”,
“field-ri”: “-240”,
“field-co”: “-360”,
“draper”: “-420”,
“canadahomebase”: “-420”,
“spokane”: “-480”,
“field-oh”: “-240”,
“melbourne”: “+600”,
“polandhomebase”: “+120”,
“warsawsupportcentre”: “+120”,
“field-ut”: “-360”,
“warsaw”: “+120”,
“israelhomebase”: “+180”,
“ontario”: “-300”,
“field-ar”: “-300”,
“bellevue”: “-480”,
“field-md”: “-240”,
“telaviv”: “+180”,
“kualalumpur”: “+480”,
“saopaulo”: “-180”,
“field-in”: “+330”,
“indiahomebase”: “+330”,
“newyork”: “-240”,
“germanyhomebase”: “+120”,
“netherlands”: “+60”,
“ukvirtual”: “+0”,
“mexicocity”: “-300”,
“sydney”: “+660”,
“guadalajara”: “-300”,
“field-mn”: “-300”,
“field-nv”: “-420”,
“tokyo”: “+540”,
“canberra”: “+600”,
“beijing”: “+480”,
“malaysiahomebase”: “+480”,
“toronto”: “-300”,
“santaclara”: “-480”,
“field-ny”: “-300”,
“francehomebase”: “+60”,
“johannesburg”: “+120”,
“irelandhomebase”: “+60”,
“field-mo”: “-300”,
“field-ct”: “-300”,
“milan”: “+60”,
“spainhomebase”: “+60”,
“czechrepublicoffice”: “+120”,
“field-or”: “-420”,
“tomsk”: “+420”,
“madrid”: “+120”,
“moscow”: “+180”,
“boston”: “-240”,
“russiahomebase”: “+180”,
“croatiahomebase”: “+120”,
“munich”: “+120”,
“brazilhomebase”: “-180”,
“turkeyhomebase”: “+180”,
“ankara”: “+180”,
“colombiahomebase”: “-300”,
“southafricahomebase”: “+120”,
“field-wv”: “-300”,
“argentinahomebase”: “-180”,
“bangkok”: “+420”,
“qatarhomebase”: “+180”,
“taipei”: “+480”,
“field-wi”: “-300”,
“field-id”: “-420”,
“stockholm”: “+60”,
“italyhomebase”: “+60”,
“switzerlandhomebase”: “+60”,
“swedenhomebase”: “+60”,
“manila”: “+480”,
“auckland”: “+720”,
“field-ia”: “-300”,
“field-pa”: “-240”,
“field-nm”: “-360”,
“field-ok”: “-300”,
“ukrainehomebase”: “+120”,
“singaporehomebase”: “+480”,
“hongkongoffice”: “+480”,
“oslo”: “+120”,
“field-mi”: “-240”,
“barcelona”: “+120”,
“netherlandshomebase”: “+60”,
“czechrepublichomebase”: “+120”,
“field-az”: “-420”,
“londonitc”: “+0”,
“espoo”: “+180”,
“zhuhai”: “+480”,
“field-ks”: “-300”,
“belgiumhomebase”: “+60”,
“brisbane”: “+600”,
“perth”: “+480”,
“field-al”: “-300”,
“australiahomebase”: “+600”,
“field-tn”: “-300”,
“chengdu”: “+480”,
“shanghai”: “+480”,
“copenhagen”: “+120”,
“field-dc”: “-240”,
“field-sc”: “-240”,
“quebec”: “-240”,
“seoul”: “+540”,
“chilehomebase”: “-240”,
“guangzhou”: “+480”,
“taiwanhomebase”: “+480”,
“chinahomebase”: “+480”,
“wellington”: “+720”,
“field-wy”: “-360”,
“field-sd”: “-360”,
“newzealandhomebase”: “+720”,
“field-nd”: “-300”,
“field-la”: “-300”,
“alberta”: “-360”,
“field-mt”: “-360”,
“hanoi”: “+420”,
“field-me”: “-240”,
“romaniahomebase”: “+180”,
“field-ne”: “-300”,
“hochiminh”: “+420”,
“bogota”: “-300”,
“doha”: “+180”,
“austriahomebase”: “+120”,
“shenzhen”: “+480”,
“bangladesh”: “+360”,
“osaka”: “+540”,
“jinan”: “+480”,
“xi’an”: “+480”,
“denmarkhomebase”: “+120”,
“norwayhomebase”: “+120”,
“field-ak”: “-480”,
“field-hi”: “-600”,
“hangzhou”: “+480”,
“finlandhomebase”: “+120”,
“moroccohomebase”: “+60”,
“japanhomebase”: “+540”,
“chicago”: “-300”,
“field-vt”: “-240”,
“philippineshomebase”: “+480”,
“hongkonghomebase”: “+480”,
“field-de”: “-300”,
“default”: “-480”
}
},
“type”: “lookup”
},
“value”: “$userTimeZoneOffset”
},
“type”: “static”
},
“m/m”
]
},
“type”: “concat”
}
}
},
“operator”: “LTE”,
“positiveCondition”: “terminated”,
“negativeCondition”: {
“type”: “static”,
“attributes”: {
“value”: {
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday”,
“attributeName”: “Emp_Status__c”
}
}
}
},
“requiresPeriodicRefresh”: true
}
},
{
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday”,
“attributeName”: “Emp_Status__c”
}
}
]
}
}
}
}
},
“internal”: false
}
Thanks
Kalyan
Thanks @kalyannambi2010!
So, first off, I would definitely recommend having your HRIS team provide you a calculated field in the IdentityNow integration within Workday with the worker’s local timezone offset rather than maintaining a table of locations and their offsets. you already have 180 separate offsets defined, it’s very likely that number will only increase over time if you keep it up this way.
In order to do this, they’d go into the Workday-side integration configured for IdentityNow and add an override field that looks at the location to which the worker record’s position is tied to, and return the GMT offset of the location. If they call the field “Timezone” in Workday, you’ll add it to the IdentityNow source schema as timezone__c (with two underscores).
This will remove a lot of complexity in your transform, as you won’t need that huge mapping table, you won’t need too pull in the Workday location and get a substring of it, no replaceAll or lower transform to get the lookup in the right format, etc.
As a visual representation of the complexity of your current transform vs what I’m suggesting:
Otherwise, we need to know what you mean by “it’s not working,” along with what locations you have where it’s not working - which locations in the lookup table translate to IST? Is the transform throwing an error, or is it just returning an unexpected value?
Lastly, have you tried breaking the transform down in your dev environment to separate identity attributes, so that you can verify that individual parts are working? If not, I’d recommend doing that so that you can determine where exactly things are falling apart for these users.
-Mark
1 Like
Hi @sup3rmark,
Thank you so much for your input. Currently the transform is not working for “hyderabad” and “bangalore” locations and the termination is not triggering during these location time zones but termination is triggering at default time zone. The transform is not throwing any error but not triggering termination during these location time zones for " hyderabad " and " bangalore " locations.
Thanks
Kalyan
Have you confirmed that the transformed location value is definitely hyderabad/bangalore for those users?
Hi @sup3rmark the location from Workday to IDN for the users is “Hyderabad (SEZ)” or “Bangalore (Non-SEZ)”.
Thanks
Kalyan
You should make a separate transform and identity attribute to see what value IdentityNow will be comparing against the lookup table. You should only need this part for that transform:
Hi @sup3rmark could you please provide more details on this for next steps and how it can be done?
Thanks
Kalyan
Hi @sup3rmark I have written new transform as below by creating a new attribute and it is populating location attribute prepoerly when I try to do preview of the user for the attribute. Could you please suggest where I am missing earlier?
{
“id”: “ccf4a31b-469a-4ead-2345-78943”,
“name”: “Sample_Transform_TempLocation”,
“type”: “static”,
“attributes”: {
“value”: {
“type”: “concat”,
“attributes”: {
“values”: [
{
“type”: “replaceAll”,
“attributes”: {
“table”: {
“\s*”: “”
},
“input”: {
“type”: “lower”,
“attributes”: {
“input”: {
“type”: “substring”,
“attributes”: {
“begin”: -1,
“end”: {
“type”: “lastIndexOf”,
“attributes”: {
“substring”: “(”
}
},
“input”: {
“type”: “accountAttribute”,
“attributes”: {
“attributeName”: “LOCATION”,
“sourceName”: “Workday - DEV”
}
}
}
}
}
}
}
}
]
}
}
},
“internal”: false
}
Hi @sup3rmark Could you please suggest where I am missing earlier?
Thanks
Kalyan
@kalyannambi2010 if that transform is returning bangalore and hyderabad, the next step would be to create another transform (and another identity attribute) that includes the same logic plus one layer up - add in the lookup transform. if that still returns the expected values, do it again with the concat transform, and then again with the datemath transform. you want to figure out where exactly this is breaking down and returning an incorrect value.
though i’d still highly recommend getting the workday team to provide you with the timezone offset directly from workday, as that’ll drastically simplify your transform and give it fewer places to break.
Hi @sup3rmark Thank you for your inputs and I have tried the steps you have mentioned like creating other tranforms like lookup and datemath transforms. I tried to do preview of the users for these transforms and the values are showing properly.
Is there any issue with the rest of the tranform like “inputFormat”: “MM/dd/yyyy” and “outputFormat”: “ISO8601” mentioned in the first section of the transform as below:
“firstDate”: {
“type”: “dateMath”,
“attributes”: {
“expression”: “+17h”,
“input”: {
“type”: “dateFormat”,
“attributes”: {
“input”: {
“type”: “firstValid”,
“attributes”: {
“values”: [
{
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday - DEV”,
“attributeName”: “LAST_DAY_OF_WORK”
}
},
{
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday - DEV”,
“attributeName”: “TERMINATION_DATE”
}
},
{
“type”: “accountAttribute”,
“attributes”: {
“sourceName”: “Workday - DEV”,
“attributeName”: “CONTRACT_END_DATE”
}
}
]
}
},
“inputFormat”: “MM/dd/yyyy”,
“outputFormat”: “ISO8601”
}
}
}
}
Thanks
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.