I have a source with an integral data type that is left padded with zeros. I assumed changing the attribute data type to int would have attempted to cast the string type and hence, remove the leading zeros.
However, it did not have any effect. I don’t see a solution with a transform, is the only option here a cloud rule?
Hi Joseph, what connector type is? Is the 0 padding giving you some error when provisioning? Being int type on IDN and system should ignore left pading 0s, if not perhaps you should change IDN attribute type to string.
Strange, I have tried with AD connector, bringing userAccountControl as int, and it only shows the number, without 0s. When you can please tell what connector type is, so I can dig in a bit more.
Hi Julian,
The AD connector userAccountControl attribute you refer to doesn’t get zero padded because the value is natively an enumeration which is an integral data type.
I am using the UKG connector, the attribute type is employeeNumber.
It is natively a string type, however the configured pattern is 6 digits, left zero padded. This could probably be some other format I am sure, but our local convention is numerical, so an unsafe cast would always work.
I think I understand better now. What I guess is that IDN attribute types in schema are only informative, as they bring what is read from source. I think any type you use will appear with the 0s in front, as they are that way in the source. If it is an authoritative source, I am not seeing other way as using a transform as you established first. But it only will throw the leading 0s on identity, I think the value will remain with 0s when you enter into the identity-s account.