We’re working on a use case in identityNow and would like to get your input.
Requirement:
We need to provision multiple accounts on the same source ( eg., ServiceNow ) for the same identity, based on the number of Active Directory ( AD ) accounts the user already has.
If a user has 3 AD accounts ( across 3 domains ), they should get 3 servicenow accounts.
If a user has 2 AD accounts, they should get 2 servicenow accounts and so on.
Is there any OOTB feature available to implement this requirement? Has anyone implemented a similar requirement?
Approach I’m considering:
Using a Before provisioning plan to manipulate the provisioning plan. The rule would dynamically check the number of AD accounts a user has, and if more than one, it would add additional create operations in the provisioning plan for the same source.
Assumption: We’ve 3 entitlements from servicenow and configured it in 3 different roles for birthright provisioning.
Any suggestions, examples would be really helpful.
ISCloud by design does not create multiple accounts in target application. I don’t think adding multiple Account Requests to the Provisioning Plan in BP rule will help.
The previous response is correct - ISC by design doesn’t support creating multiple accounts on the same source for a single identity through standard provisioning operations. This is a fundamental architectural limitation of ISC.
While ISC does support having multiple accounts on the same source (you can see multiple accounts in the UI for one identity), the provisioning engine will always try to modify an existing account rather than create a new one when provisioning access. When ISC detects that an identity already has an account on a source, it converts what would be a create operation into a modify operation on the existing account.
The “Provisioning Criteria for multiple Accounts” feature in access profiles is designed to help ISC decide which existing account to modify when multiple accounts already exist, not to create new accounts. This is different from what you’re trying to achieve.
Your proposed approach of using a Before Provisioning Rule to add multiple create operations to the provisioning plan won’t work because ISC’s provisioning engine will still recognize that accounts already exist and convert those operations back to modify operations before executing them.
For your specific use case of needing ServiceNow accounts to match the number of AD accounts, you’d likely need to implement a custom solution outside of standard ISC provisioning, such as using workflows with HTTP actions to directly call ServiceNow APIs to create the additional accounts, or implementing this logic in an external system that ISC triggers through an event-based workflow.
If you know the number of domains, then you could potentially have a separate connection to ServiceNow for each. You would need to have an attribute on the ServiceNow account that could be utilized in the Aggregation Settings Account Filter, to keep the accounts separate on each source.
In your Roles, you could use the presence of Domain Users on a given AD domain as criteria for provisioning a ServiceNow account on the related connection.
I’ve used separate connections in the past to create separate AD accounts, but have never done so with ServiceNow, but I assume it would work similarly.