I’m looking for some advice or best practices on how to replicate Entra ID dynamic group behavior within SailPoint Identity Security Cloud (ISC).
Use Case
I have 20,000 Entra ID groups that require 1:1 dynamic mappings based on identity attributes. A common pattern looks like this:
If identity.company = Company A, then the user should be placed in the group EXT - Company A
If identity.company = Company B, then they go into EXT - Company B
… and so on across 20K values.
What I’ve Considered So Far
Roles: From what I understand, roles aren’t intended for this kind of high-volume, 1:1 mapping. It feels inefficient and hard to maintain.
Dimensions: These seem limited to around 1,500 entries, so they won’t scale to 20,000 values.
Workflows: I’m wondering if custom workflows (triggered on identity updates) could evaluate the company attribute and assign the appropriate Entra group?
My Question
Has anyone implemented a scalable solution for this in ISC?
Would it be better to:
Keep these group mappings in Entra ID using dynamic groups, and simply manage attribute values from ISC?
Use ISC Workflows to dynamically assign group memberships based on attribute values?
Build a hybrid model, where ISC manages identity data and Entra handles dynamic group logic?
Hey @trohrman -
I think you’re already there: Workflow (plus a one-time PS Script) is the way to go.
Create a workflow with the identity attributes changed trigger:
Filter the attribute changes on your intended company identity attribute.
Look for previous value being null and the new value being Company A or Company B. This is because you don’t want your workflow to trigger for every possible company attribute change, only the very first instance of it (Alternatively, if you think this has potential to change and needs special handling, feel free to ignore this step)
Use the Manage Access step to make a ‘Submit Access Request’ API call to submit an access request to grant the intended Entra group. Note that this requires the entitlements to be requestable on ISC.
The above workflow works well if you intend to do this as a one time joiner activity.
However, for existing users that need to be processed in the same fashion, write a PS script which:
Goes over every user with an Entra account (Use Search API),
Checks if they belong to Company A or Company B and accordingly makes an access request for the mapped Entra group.
For this script, use the PowerShell SDK so that you don’t have to do the heavy lifting.
This script can be considered as a one time activity, because your future changes will go through the workflow.
Hi @Tyler_Harman can I challenge the premise? Why do you want to replicate the group functionality in ISC? Anything you do, IMHO, would be over-engineering. Think of dynamic groups as attribute access (ABAC) and manage the attribute accordingly, which I think is your option 1, not sure I see the diff between that and your option 3? I take it you are already aggregating accounts? Are you provisioning also?
Hey Jeremy, no I appreciate the response! I guess 1/3 are virtually the same.
I am provisioning the accounts and aggregating. The full flow is SNOW > NERM > ISC > ENTRA
On initial creation they are dynamically added to a role which includes an Entra entitlement and therefore provisions an account.
This is when I will want the company value read and them added to an additional Entra group. If that value changes, I will want the group membership to also dynamically change.
If the answer is just use Entra dynamic groups with attribute sync to company enabled, I’m 100% okay with that, just wanted to explore what options ISC had that could work similarly for this large of scope. It seems like this is what dimensions would be used for but just limited to 1500.
Thank you to both others, I think workflows/PS may be the way to go here if I want to keep the assignment logic in ISC.
PS should be able to handle the logic pretty easy too.