How to dynamically filter a 'contributor select' dropdown based on the requester's hierarchy (Manager/Subordinates)?

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

:bangbang: Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.,

We are designing a request model for non-employees in NERM and we have run into a strict business requirement: the internal sponsor (manager) of the request must be selected from a list of valid internal employees, and free-text fields are strictly prohibited.

To achieve this, we need the internal sponsor selection field in the initial Request Form to be dynamically filtered based on the requester’s identity. We are exploring two options for the dropdown:

  • Option 1: Show only the Requester, their Manager, and their direct Subordinates.

  • Option 2: Show exclusively the Requester’s direct Subordinates.

What we have investigated and our current roadblocks:

  • System Users vs. Profiles: Since our internal sponsors are actual System Users (Contributors) and not managed Profiles, we are forced to use a contributor select attribute in the form to capture them.
  • Backend Visibility: We know that in the native administration interface, under System > Users, you can view the relational table of each user’s managers and managed users. We can also retrieve these relationships by making calls to the NERM API (e.g., /api/user_managers?user_id=...). However, we have not found any native way to use this relational data to filter the form in real time.
  • Liquid Template Limitations: We know that Liquid Template Language is supported on Workflow Pages and API Actions, but we cannot use Liquid to dynamically populate or filter the options of a dropdown menu inside the form.
  • Lack of Dynamic Filters: The fundamental issue is that the only native filtering option for a contributor select field is the static Add role configuration, which only restricts users based on the roles they have been assigned in the system. It does not support dynamic relational filtering.
  • We know that if we were working with Profiles, we could use a profile select attribute, which does support advanced conditional filtering by crossing a Filtering attribute with a Filter. However, we want to avoid syncing our internal workforce as Profiles just to get UI filtering, as this would break the native approval routing capabilities for System Users in our workflows.

My question to the community:

Is there any technique to dynamically inject the list of managed users into the options of a “contributor select” field? Or should we assume that the only supported architectural solution for achieving this filtering in the interface is to stop using
System Users for this selection and instead synchronize internal employees as Profiles?

Any ideas, alternatives, or shared experiences dealing with this exact scenario would be greatly appreciated.

I share with you some screenshots from our Lab.

Thanks in advance!

image
image710×630 32.8 KB

{
    "user_managers": [
        {
            "id": "id",
            "uid": "uid",
            "user_id": "user_id",
            "manager_id": "manager_id"
        }
    ]
}
2

Hello Marcos. Your conclusion on contributor select looks correct. Its documented filtering is role-based, and I do not see a documented way to dynamically restrict it by the requester’s manager or subordinate relationships.

For Option 2 (direct subordinates), a Profile-based model could work. Model employees as Profiles with a Manager relationship, then use a profile select for Sponsor and filter it against the requester’s Employee profile selected earlier in the request.

The main prerequisite is resolving the requesting System User to the correct Employee profile, since the documented filter works from a previously populated Profile attribute.

Using Profiles also does not necessarily break approval routing. If the Employee profile has the corresponding System User as owner or contributor, the Approval Form can route using “Contributors from another profile” or “Selected contributor.”

For Option 1 (requester plus manager plus direct reports), I do not see a documented native single-field OR filter.

3

I’ve seen this requirement myself before, and using only the contributor select, this is not possible. The problem is that the contributors are based on ‘users’ and this object type doesn’t hold any such data.

What could be possible is ingest the whole Employee structure into NERM into a separate profile type (e.g. employees) and have a profile select / search instead. Each user then needs to be linked to an ‘Employee profile’ and then based off that do some filtering.

I haven’t personally tried this approach, but you could give it a shot in a small PoC.

4

@sauvee @punna0001

Hi guys!
Thanks for sharing your approach.

For me, what is really confusing is the strict separation between System Users and Profiles regarding hierarchical data. From the UI > System > Users, you can see the Manager and Managed Users of a user, and you can also extract this via the “Get user-manager relationship” API call. However, this data doesn’t seem directly available to populate form dropdowns.

Just to clarify what we’re trying to achive

Context

  • We have Internal Employees that are created from ISC. This users arrive to NERM as Users. In ISC they already have a manager so, could we create the Users with this relationship stablished?
  • This Internal Employee should be able to create External Exployess. For this we use a Form, in witch the requester must fill a filed call Internal Manager.
  • This Internal Manager would be the responsible/owner of the External for approving process, renewals, etc…

Selecting the Internal Manager

  • The requester needs to choose the Internal Manager from three possible scopes: themselves, their manager, or one of their subordinates.
  • As we’re seeing, have all the option in one list is imposible, so we’ve come with the solution of ussing Radio Buttons or something similar, so only if the requester choose the “Subordinete” option, a list o they subordinate displays.
  • The option selected needs to be set in the Internal Manager attribute (Contributor Selects/Search type).

Approval Phase
Then, depending of the Internal Manager selectec we have different types of approval needs. This is why is important to have set the Internal Manager attribute to point to the correct user.

  • If Internal Manager = Themselves (Requester): We need approval from the requester’s manager, followed by the requester.
  • If Internal Manager = Requester’s Manager: We need approval from the requester’s manager (who is the Internal Manager) and their superior.
  • If Internal Manager = Subordinate: The approval should come from the Requester (acting as the Subordinate’s manager), and the subordinate will only receive a notification.

If using Users to do this ap

proach is not abiable (as it looks like), has anyone successfully mapped the System User manager hierarchy into a profile select attribute, or used Reverse Relationships to dynamically filter a dropdown of subordinates in a form?

Any insights on streamlining this dual-model approach would be highly appreciated.

{
    "user_managers": [
        {
            "id": "id",
            "uid": "uid",
            "user_id": "user_id",
            "manager_id": "manager_id"
        }
    ]
}

image
image355×281 6.07 KB