Interactive form - get select field to only include direct reports

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hello community!

I am working with new features available in workflows from privileged task automation.

Problem to solve:
My organization doesn’t not provide a way via the HR system to process an immediate/emergency termination, instead the manager will call a 24/7 call line the IAM team operates. We would like to provide a URL to the launcher that allows any employee in our HR system that has direct reports to use this launcher.

Roadblock:
I can’t seem to figure out an ideal way to present the manager a list of only their direct reports while also passing the ISC ID value for further work.

What I have tried:

  1. Passing a list of identities (the direct reports of the user launching the task) in the form input that is used to populate select field, downside of this approach is only the value presented is passed in the workflow. If I choose displayName as the primary value/label and employeeId as the sub-label then the workflow only receives the displayName. I think I could work with this where the primary value is the employeeId but I don’t love the UX of that.
  2. I have attempted to craft a search query as a define variable and pass that to the form in form input. Then have the select field perform that custom search to populate the options.

inline variable here is the ISC ID if the manager submitting the form.

image
image443×916 22.9 KB

Inline variable is the entire search query from above being passed.
image
image468×927 23.2 KB

A workaround I thought of is to present all identities and if they select one that is not their direct report it will fail and ask them to try again. Or to present an ugly value to the user with the sublabel being more recognizable.

Ultimately, I expect the workflow to look something like this.

image
image335×670 21.4 KB

I referenced this documentation to see what might be possible.
Forms - SailPoint Identity Services

Thanks for any feedback!

2

Hi James,

One potential workaround that I can think of is to use the “Display Name” version of the dropdown, and use the returned display name along with the manager’s ID to perform a search for the correct identity ID.

You can use the “HTTP Request” action to call the Perform Search API with the following body:

{
  "indices": [
    "identities"
  ],
  "query": {
    "query": "attributes.displayName:\"<Display Name>\" AND manager.id:\"{{$.form.input.launcherId}}\""
  }
}

Where the “Display Name” comes from the form selection.

Then you can reference $.httpRequest.body[0].id wherever you need to perform an action on the identity you are terminating. Of course, this relies on the assumption that the manager does not have two direct reports with the same exact name but absent of using employee IDs in the dropdown I do not think there is a workaround for that edge case.

1 Like
3

Thanks for the suggested workaround. I may end up going that route. I may present the employee ID as the primary value in this case with the display name as the sub-label. I’m not about to rule out the possibility a manager having two employees with the same name.

4

I ended up finding a much simpler way of doing this OOTB.

User the “Get List of Identities” and configure it to use Find Identities By Managers and point at $.trigger.launchedBy.id.

Then in the form you present them you can pass $.getListOfIdentities.identities[?(@.attributes.cloudLifecycleState == “active”)] to the select field of direct reports.

What I was getting hung up on before what that when they selected someone it seemed to pass me the name or emp ID in the workflow, I just misunderstood the purpose of “Array Value”, Setting it this way got me exactly what I wanted!

With it configured this way the dropdown only contains helpful information to the manager and still passes the Identity ID downstream.

image
image384×670 16 KB

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.