We are working on setting up conditions for onboarding new non-employees in NERM. Specifically, we aim to create different approval flows based on the requester’s role (the person who initiates the workflow).
For example, if the requester is a Sponsor, no approval is needed.
However, there is no indication of the user’s role in their attributes within the UI. Additionally, I couldn’t find a way to retrieve the role group value via the /users/
API call.
Does anyone have any ideas on how to retrieve the user role value for a specific user? Has anyone else tried to use user roles in workflow conditions?
This has come up from time to time (and I invite you submit this use case to the SailPoint Ideas Portal! ) and there isn’t a great workaround for it.
I do want to note that the Approval Form itself can be configured to be skipped ( Workflow Actions - Admin Help) if the Requester is also an Approver. So, if you, for example, set the available Approvers for the Approval Form to the “Sponsor” User Role and check off “Skippable Approval” - it would allow for the Approval to be skipped by any requesters who are sponsors.
However, that does have the side affect of then allow any other “Sponsor” being able to Approve that workflow or sending them a notification for it (if that is configured) instead of just skipping the whole action.
You could use the get-user-roles endpoint in a REST API action with the requester’s User ID and that would return any roles that are assigned to that user. The data mapping in REST API actions is pretty static, so you can’t really capture all of the returned Role IDs unless you map them individually like:
user_roles > 0 > role_id => attribute_uid_1
user_roles > 1 > role_id => attribute_uid_2
etc…
So, the better choice (if you have a finite amount of roles that you want to check for and skip the actions if the requester has it) would be to check for specific roles in the REST API call. That request URL would look like
Then, you can data map the returned ID to a text attribute like user_roles > 0 > id => attribute_uid_1 . Then, in a condition, you could just check if attribute_uid_1 is absent . True means they enter the condition and perform the Approval; False would skip over that action set.
Again, this would only really work for a finite number of User Roles each role would need its own REST API action.
In our use case, we have a finite number of internal user roles and want to create different conditions based on the requester’s user role and the organization’s risk score. As you can understand, as more user roles are created, we may end up with a workflow containing numerous REST API actions and conditions. Nevertheless, I tried your suggested workaround, and it works perfectly.
I will submit an idea for this since having user role as attribute may offer a lot of value.