We’ve to generate proxy address and targetAddress value based on AD Email value, which will be calculated based on Attribute generator rule written for mail attribute. I would like to understand the sequence of value generation for AD account attributes. I can just use the value generated by attribute generator rule in the below attributes directly or do I need to use the same logic of email in attribute generator rule for below attributes and then populate accordingly the value
targetAddress = “SMTP:” + AD email
proxyAddresses = SMTP: AD email
If you’re generating this in the source create profile, then they are generated in order - so as long as the AD Email address is higher in the create profile, it will be generated first and can be referenced for your targetAddress and proxyAddresses.
Simply use the $ notation to reference another attribute. For example:
If you’re generating this in the Identity profile, I do not believe there is any order guarantee and it’s not recommended to have one identity attribute depend on another for this reason.
@Ramiro Thanks for the input. It worked fine. For proxyaddress also we would like to generate the values as below during account creation of AD. proxyaddress is multivalued attribute, so we should use attribute generator rule to do this or can be done in simple fashion. We would like to avoid cloud rule creation. Both mail and userPrincipalName is available
proxyAddress: SMTP:$mail
$userPrincipalName
We required a BeforeProvisioningRule to generate a multi-value attribute in the past. That was three years ago though, so it’s possible that something has changed in the meantime which allows the create profile to specify multi-value attributes, however I do not believe there has been.
Maybe someone from SailPoint can confirm this.
One thing I would recommend for multi-value attributes is to create a single BeforeProvisioningRule which can convert a single-value delimited string into a multi-value attribute, and reference the source configuration to determine which attributes to convert.
This will be a bit more effort upfront, but then it would allow you to define multi-value attributes in any source by using the source configuration and create profile only, and you’d never need to touch the rule again.
In general when using rules it’s always best to write it in as generic a way as possible so you can be in charge of your configuration.
Thanks for this. I’ll have a look. I’m trying to generate mailNickName based on email. Eg: [email protected] then mailNickName should be SEEMA.RANI. In order to do that I’ve created V3 transform and tested that transform at identity profile level. The value is coming fine. But when I attach the transfrom at AD account profile, I’m not seeing any value in mailNickName and also this attribute is not provisioning plan. The mail attribute is appearing before mailNickName in AD account profile. Any idea what could be the issue
Are you referencing the $mail attribute in the transform itself? I am pretty sure that doesn’t work, you need to directly reference $mail in a static transform in the create profile.
If your transform is complex and you want to separate it from the create profile, you can simply pass the $mail attribute in as input into the transform from the create profile, it has to be done via API though as the UI doesn’t give enough flexibility.
Something like this should work (I haven’t tested this):
Just would like to understand we’ve generated the mail values using attribute generator rule in Create profile, but the same generated unique value should be added into proxy address using before provisioning rule. How we can achieve, during this time how we can fetch the value generated using attribute generator rule. Any suggestions?
Eg our mail attribute generator rule generated value say [email protected] and our userPrincipalName = smtp:[email protected] and the proxyaddress value should be as below.