This release improves Identity Security Cloud’s automated role assignment capabilities. Enhancements include the addition of new standard criteria operators and an improved role admin user experience. These updates make it easier for you to implement birthright provisioning processes and to enforce least privilege for your organization.
Enhancements include:
A Does Not Contain operator has been added for Identity and Account attribute expressions.
Starts With and Ends With operators have been added for Account attribute expressions.
Numeric attributes are now supported for Account attributes.
The >, >=, <, <= operators have been added for Account attribute expressions.
Null values for boolean attributes are now handled correctly. Identities without an account will no longer be incorrectly selected based on account selection criteria.
A single criteria expression can be used to evaluate a list of values. For example, you can now evaluate if a user’s department is equal to Accounting, Finance, or Accounts Payable in a single statement. Previously, this would have required 3 separate OR statements. Each value list can contain up to 25 values.
Enablement of this capability will begin the week of June 30th 2025. All staging environments will be enabled first with production environments following in stages.
By RSVP’ing to this event you will be reminded of this release prior.
Now we just need a “what roles leverage the department identity attribute” or “what roles use the department equals accounting expression” to help quickly analyze role impact of attribute changes
Null values for boolean attributes are now handled correctly. Identities without an account will no longer be incorrectly selected based on account selection criteria.
Wait - I was going batty a couple weeks ago trying to figure out why my role (which was using a boolean evaluator) was adding every identity even though the logic was sound. You mean to tell me this was a bug?!
Thanks for the update, Patrick — these enhancements look great! Out of curiosity, will this improved criteria evaluation logic also be extended to other areas in ISC that use similar evaluation patterns? For example, the classification rules in the Machine Identity Security feature? Would be great to see consistency across the platform.
I’ve had a few other customers ask for this as well. Do you know if there’s already an idea raised for it on the Ideas Portal? If not, it would be great to get one logged.
Great enhancements, thank you!
I am sure this allows our role modeling team to make more elegant membership criteria.
Not sure if they exist, but for the customers who actually meant to select all identities who either have no account, or have an account with the boolean value being null, who tested this in the past, saw it worked and put it into production, what is their alternative now? Have they been informed in a timely manner to reevaluate and update their membership criteria, or will they now be unpleasantly surprised with an announcement 3 days before it might go into effect? If they missed this announcement in these couple of days, will ISC now suddenly start deprovisioning the access of many of these identities?
Good enhancement. but it still lacks ‘isNull’,‘notNull’ conditions. Also, will there be enhancement for the dimensions criteria where we can use ‘contains’ instead of ‘equals’
Any tentative dates for prod release of this feature?
Appreciate the continued innovation and focus on improving identity security, automation, and user experience. Looking forward to exploring the new features and enhancements in this release. Great work by the SailPoint team!
I really look forward to using this update, the lists (effectively an extra level of OR) is a great addition. Can I ask though - what is the reason for the 25 item limit? It seems a bit arbitrary;
can I be the first to ask for this to be extended or made unlimited, even?
This is actively harming the user experience for administrators. You have literal dozens of ambassadors and expert ambassadors (i.e. people who are active proponents of your tools, engaged with the community and customers, and experienced users) saying that this is detrimental, and yet SailPoint continues to proliferate this change anyway.
It’s just really disappointing to see the community feedback so blatantly ignored.
If your company has databricks, it’s not a relatively easy solution but I just moved some of our SailPoint configuration data such as roles and access profiles into databricks (using the following guide: SailPoint and data lake houses). This way we can use SQL queries to do things like check for any Roles that key off of a certain department or anything like that for this exact reason.
We use CSVs to maintain our Roles, and we import these CSVs through the VS Code extension.
I created a Role in our Sandbox to see what the output CSV would be (exported with the VS Code extension) so I could refine my script that generates the CSVs for import.
It seems the VS Code extension does not handle these new “multivalue” fields.
"Test Multivalue","Testing new multivalue criteria",true,false,"My.User",false,false,"",false,false,"","","","identity.cloudLifecycleState eq 'null' or 'HR Data'.attribute.myattribute eq 'null'"
Lifecycle State was set to 1 value ‘active’ and the myattribute was set to 3 different values. But as you can see the CSV output is ‘null’ for both, this will cause us issues managing our roles.
What are the plans for the VS Code extension and support of this feature?
Idea GOV-I-1523
By RSVP’ing to this event you will be reminded of this release prior.