Hi! I have a question about available attributes inside a provisioning plan and how to access them.
Longer explanation is that we have a JDBC source with a functioning provisioning plan but there is one issue: currently we use plan.getNativeIdentity() to generate the account username but we’d prefer to use the work email identity attribute.
This is mapped inside the Create Account configuration for the source (ACCOUNT = work email) but it doesn’t seem to have effect on the provisioning plan. The reason for this is getNativeIdentity is immutable and there can be scenarios where this is different from work email (we use the same value for originally creating the identity, but email changes are a common occurrence).
Is there a way to use identity attributes inside a provisioning plan? If so, how are they called and what module should I import?
Regarding the Create Account configuration, this only seems to work for setting the Account Name inside the account schema in Sailpoint when a new account is provisioned but it doesn’t affect what is actually sent to the source.
@M_rtenH I cannot understand your configuration fully. Can you share some screenshot of configuration so that kind of helps me understand what is your current config and what you are trying to achieve.
For other sources, the Create Account configuration seems to work in way that it overrides the getNativeIdentity value so we can sync it to various identity attributes during provisioning operations.
For this JDBC source, that doesn’t seem to happen - getNativeIdentity value is sent to source instead.
What I want to achieve is to use the email identity attribute inside the provisioning plan instead of getNativeIdentity when provisioning new accounts.
Inside a provisioning plan, plan.getNativeIdentity returns an identities Sailpoint username - correct?
I need a variable that would instead return an identity attribute, namely email address.
The requirement is that accounts in this JDBC source need to be provisioned using their Work Email attribute (as visible in the screenshot from Create Account conf) instead of their Sailpoint username - currently plan.getNativeIdentity always returns their Sailpoint username instead, despite what’s configured in Create Account.
If it helps, then the problem I’m trying to solve is that the Sailpoint username is an immutable attribute - the only way to change this is to remove an identity and rebuild it via aggregation from your main identity source.
Downstream application accounts (in this case, the JDBC source) use, in our instance, work email addresses as login/username.
If a user changes their work email due to name change or other reasons, we need to change their downstream application accounts accordingly and automatically.
Inside a provisioning plan, plan.getNativeIdentity returns an identities Sailpoint username - correct?
—> plan.getNativeIdentity returns accountId of identity and not username. Open any identity and you would see accountId identity attribute, it is returned by this method. In your case both of these attributes might be holding same value so saying “plan.getNativeIdentity returns an identities Sailpoint username” might be true for your environment but I wanted to make sure you understand the concept. On top of it accountId of identity gets decided by accountId attribute of your authoritative source. If employee number is marked as accountId on your workday auth source then you would see that value as accountId on identity itself.
I need a variable that would instead return an identity attribute, namely email address.
→ Looks like you need email attribute which is account id in your source schema. This is called nativeIdentity also for that source. You can get this by calling accuntRequest.getNativeIdentity method.
First you need to get plan.getAccountrequest and then get native identity from it.
Method names might not be proper so refer documentation for it.
I cannot help here for your use case of changing email and provisioning to downstream as it is quite complex because whenever any attribute which is used as accountId gets changed, it is not same account or identity for identitynow anymore.
That’s perfect, thank you. I appreciate specifying what plan.getNativeIdentity returns specifically - it’s good to know these details.
I’ve had success with using accountRequest.getNativeIdentity method and that’s exactly what I was missing.
In regards to “refer to documentation” - could you potentially point me in the right direction for this? I’d love to educate myself instead of posting on the forum on this topic but I haven’t really been able to find anything in depth when it comes to provisioning rules/plans.
