The Google workspace connector has some complex attributes which need to put in a json format in order for Google to accept them. The json can be done by a transform, I can do the transform in the Create provisioning policy or I can create identity attributes and do the transform there. I prefer to do it in the Identity profile because I also want to sync the attributes to Google and direct sync from the identity profile works well rather than the zig-zag update provisioning policy.
My concern with doing this in the identity profile is suppose I have 20 other applications with such requirements does it mean I create say its 4 complex attributes per application, 80 attributes in the identity profile? I want to know if its best practice to put such application attributes in the identity profile? In all my years as an IGA architect I have preferred to extend the master profile and flow that to target source, But then you can hide the data massage in the code. In ISC there isn’t that code flexibility advantage. So okay if I extend the identity profile schema to accommodate all my application needs?
Hi Ike,
Thank you for the post. We also had a similar requirement and had created Identity Attribute on Identity Profile. We did not see any issues in the same.
If you need to do attribute sync, then there should be an Identity attribute created, no other way.
I understand that, creating 80 attributes is a lot to take, but we don’t have a choice here.
But there is a way, you can reduce the number of attributes, if there is any dependency on these attributes.
For example, if attribute2 will be updated every time attribute1 is updated and vice versa. Then you do not need to create identity attribute for both of them, one is enough. Remaining one, you can add in Update Provisioning Policy form. We just need one attribute that triggers the update operation, we will have remaining attributes in update provisioning policy form.