I am currently working on a scenario where an identity has two accounts on SourceA: a primary and a secondary. These accounts need to be replicated on SourceB. While the primary account is correctly created when the identity requests a Role/Access Profile for SourceB, the secondary account is not yet established.
This raises two key questions:
How can we manage the creation of the secondary account on SourceB?
How can the identity request a Role/Access Profile for SourceB if the secondary account is not yet available?
I would greatly appreciate any insights, best practices, or solutions you might have encountered for handling such scenarios. Looking forward to your thoughts and suggestions!
Well ! While Sailpoint Cannot directly handle multi-account creation , what we can do is
In JDBC Provisioning rule :
For create operation , execute a query to create this secondary account , with the same attribute that are collected in the plan ;
For Modify Operation , execute query to modify this secondary account , using the plan data .
Thank you for your suggestion! I was wondering if it would be possible to implement a slightly different approach to handle the creation of the secondary account. The idea would be to create a dedicated role that, when requested, instead of assigning it to the primary account, searches for a secondary account and creates it through the “Before Provisioning” rule.
However, there’s an additional complexity: if the identity has multiple secondary accounts, we’re unsure how to decide which one to create. Do you have any advice or best practices for handling this situation? Is there a way to define a selection logic based on specific attributes or other conditions?
Thank you again for your support and suggestions! Looking forward to exploring this further.
One possible solution would be to enhance the Before Provisioning rule for SourceB so that it checks whether the identity already has a secondary account on SourceA. If so, the rule can drive logic to create the corresponding secondary account on SourceB as part of the provisioning event, instead of relying solely on the default behavior tied to the primary account.
Alternatively, if your system distinguishes between primary and secondary accounts (perhaps via an account type or custom attribute), another scalable option would be to configure two separate identity sources:
SourceA1 for aggregating primary accounts
SourceA2 for aggregating secondary accounts (with filtering logic based on that attribute)
This separation allows you to manage provisioning triggers and access requests more cleanly, and gives you flexibility to map roles or Access Profiles differently depending on account type.
For your second question — enabling the identity to request roles for the secondary account even if it doesn’t exist yet — this would likely require a custom front-end flow or a form-based request that triggers the provisioning of the secondary account on SourceB as part of the submission process.
I’d do this with 4 different sources: “Source 1 Primary”, “Source 1 Secondary”, “Source 2 Primary” and “Source 2 Secondary”. Ensure your filters for each source enable aggregation for only the correct account types. From that point it’s all standard provisioning behavior.