I’m working on an IdentityIQ 8.4p2 implementation where a single AD application must support multiple account families (e.g. K and S accounts).
Each IT Role has its own Account Selector Rule:
K_ROLE → K account
S_ROLE → S account
The selectors work correctly when roles are requested individually: each selector returns the correct existing Link or new Link().
The appropriate account name is calculated into the application’s create provisioning form.
However, when K_ROLE and S_ROLE are requested together and neither account exists, IdentityIQ compiles the provisioning plan into a single AccountRequest:
As a result, the entitlements from both roles are provisioned to the same newly created account instead of creating two separate accounts.
allowDuplicateAccounts=true is already configured.
Has anyone encountered this behavior with multiple Account Selector Rules targeting the same application? Is there an IdentityIQ configuration or supported approach that forces the individual account creation requests to remain separate instead of being merged into a parent AccountRequest/follower structure?
Since you already have allowDuplicateAccounts=true, I would also confirm in the Role Editor that Allow multiple application accounts is enabled on both K_ROLE and S_ROLE. SailPoint documents this role option as allowing roles targeting the same application to use separate accounts. (Multiple Application Accounts)
Then, as a test, return "prompt" from both Account Selector rules when the K or S account does not exist, instead of returning new Link(). SailPoint specifically documents "prompt" for multiple IT roles targeting the same application so that account selection occurs separately for each role.
Request K_ROLE and S_ROLE together and verify that IIQ prompts for the target account separately for each role. If account creation is allowed, select Create New Account for each.
If that creates separate K and S accounts, but the automatic new Link() path still merges them into one parent/follower Create, I would raise that behavior with SailPoint Support. I could not find a documented 8.4p2 setting that disables that automatic merge.
@mp002 You might want to share the app xml, bundle xmls and selector rule xml to review it better. You should be able to achieve this with a single rule as well. but can confirm only after seeing the artefacts
@punna0001, I can confirm that the “Allow multiple application accounts” checkbox is selected for both roles.
I tried modifying the rules as you suggested, using `return “prompt”` for testing. As expected when manually requesting the roles, a form opens where you can select “Create New Account.” When I select this for both roles, I get the same merge result when submitting the request.
@neel193, I’m attaching four files that are the main parts I’m working on:
Plan.xml: the result of the simultaneous role request
S_ROLE.xml: one of the roles (the K role is practically the same)
Selector.xml: the rule present in S_ROLE (the K rule is practically the same)
Application_DynamicAttribute.xml: the code in the app creation form that calculates the name of the new account.
Thanks Marco. Your Plan.xml shows that IIQ ends up with one K account Create, while the S account Create is stored under followers without its own nativeIdentity.
One more test I would try is to set the full AD nativeIdentity/DN directly in each Account Selector when creating a new account, instead of calculating it later in the provisioning policy. SailPoint documented this behavior for IdentityIQ 6.3p1 and later. A new Link returned by the Account Selector can carry the nativeIdentity for the account.
For example, have the K selector return a new Link with the K DN and the S selector return a new Link with the S DN.
Then request both roles together and check the plan again. Ideally, you should see two separate Create AccountRequests with different native identities.
I would treat this as a test rather than a confirmed fix for the merge. If IIQ 8.4p2 still creates the same parent/follower structure with two distinct DNs supplied by the selectors, I would raise that plan with SailPoint Support. I did not find another documented setting that forces those automatic Creates to remain separate.
Hi @punna0001,
Could you share the Sailpoint documentation you’re referring to?
Because into the “AccountSelectorRule” description there is this:
a new Link instance - indicates that a new account must be created with the identity specified by the
create policy, or manually; in this case, the Link instance returned will have a null nativeIdentity attribute
The wording you quoted is the standard AccountSelector description.
There is also later SailPoint guidance under ETN 21488, introduced in 6.3p1, in the Wiki article “How to set the nativeIdentity value for a new account with a role.” That guidance documents that a new Link returned by the Account Selector can carry the nativeIdentity for the new account. The Community article is currently unavailable due to SailPoint’s ongoing migration.
For one controlled test, I would have:
the K selector return a new Link with the K account DN
the S selector return a new Link with the S account DN
request both roles together and inspect the compiled plan and provisioning result
If both DNs are retained and two accounts are created, IIQ is honoring the selector-supplied native identities. If one DN is lost, or both roles still provision to the same account, I would raise it with SailPoint Support.
@neel193 If that’s what you mean—assigning a single role, and therefore using a single account selection rule—then yes, the process works. The specific account is created successfully.
@mp002 What i meant is having the same account selector rule in multiple IIQ roles and try assigning them together. In the rule, based on rolename, you can return the link.
I followed your suggestion to set a “nativeIdentity” (DN in this case) on the link returned by the account selection rule, and it seems to be working.
I’m testing the entire process with this setting, and it appears that iiq understands that K_ROLE and S_ROLE refer to two different accounts. In fact, during the creation phase, I can now see two different AccountRequests in the plan.
I’ll take a look at the document you mentioned as soon as the link is available.