IdentityNow uses ISO8601 as default date format on many locations. One can see this in transforms on the dateFormat transform. If one does not specify the outputFormat, the ISO8601 format will be used. If one does not specify the inputFormat, the ISO8601 format will be used. The dateCompare transform expects all data to be in the ISO8601 format for it to work.
It seems odd to me that the dateMath transform is not adhering to this standard. Although it does expect the input to be in the ISO8601 format for it to work, the output oddly uses a different format (yyyy-MM-dd’T’HH:mm). The documentation even mentions this and tells us to always nest this transform in another dateFormat transform as workaround to this break of convention.
I understand that since many tenant are currently using the transform in the way it works now, it would be difficult to fix this break of convention. But could we get another parameter in the dateMath transform, where we can specify the outputFormat directly? Then we do not have to nest our transforms each time we want to use the dateMath transform.
Hi @angelo_mekenkamp , did you get any feedback on this topic? I would also love to avoid using multiple transforms that could be replaced by one transform that supports additional parameters / having a constant input/output format.
Thank you for your response, good to know I am not the only one experiencing this issue.
There is a vote button on this page to this feedback I have given. Could you please click on it? Perhaps it will have an effect from SailPoint’s side.
I am slightly afraid that SailPoint is hesitant to improve the behavior of the transforms though, because the transforms are already being used a lot and there does not seem to be a versioning of transforms, allowing tenants to upgrade to the latest version of a transform at their own convenience. So any change made to transforms might break current use of it.
I can name a couple of other transforms with behavior people might consider undesired, that probably won’t be fixed anymore, or at least not in the first couple of upcoming years.
For now my way to go is to look for workarounds (keep using nested transforms; create a dedicated transform that immediately does the conversion and refer to that transform, or go for an option that does not rely on SailPoint’s transforms, perhaps by using a rule or an external/third party script), but all of this does indeed increase complexity, which I understand is not what you expect.
I think this issue can be easily overcome.
Adding another field, like version, would allow to select one of the newer versions. Yes, they would have to maintain two behaviours, but for this simple transforms this should be easy enough, with huge benefits.
I would love to know what SailPoint has planned for transforms, even an official message that nothing is going to be done in the next 2 years.
Yes, that would be the solution I would use as well. Not sure if only two behaviours need to be maintained though. What if they update a transform, then update it again a week later. We would then expect SailPoint to be able to have all 3 versions working. But I leave that up to SailPoint to design.