Business Roles with IT roles that can be auto assigned as well request based

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

Hi All,

I have a requirement to design a custom form where the form needs to pull all the entitlements of the particular user who is accessing the form. On submission, a particular worflow gets triggered. What is the optimal way to achieve this.

  1. To identity the user id based on the session
  2. Pull the entitlements based on the id

Thanks

2

Hi @nmuthusamy ,

I would recommend using the authenticated user’s context instead of trying to identify the user from the session manually.

  • Use the /v3/auth-user API to get the logged-in user’s identity.
  • Use the returned identity ID to fetch the user’s entitlements via the ISC APIs.
  • Populate the form with those entitlements.
  • On submission, pass the selected entitlement(s) and identity ID to your workflow.

Thank you.

3

Hi @nmuthusamy ,

Please check below script, if it fits into your requirement, else provide more context on the ask,

Kind regards,

Aayush

getidandentitlements20260803.json (1.7 KB)

4

Hello Narmada. The approach you want is an Interactive Process workflow rather than a standalone form with a Form Submitted trigger. The difference is timing: a Form Submitted workflow starts only after submission, so submittedBy.id cannot populate the same form before the user sees it.

With an Interactive Process, the user launches the workflow from the Launchpad, and the Interactive Trigger provides their identity ID through $.trigger.launchedBy.id. That covers the first requirement without needing a separate API call.

For pulling their entitlements, add a Get Access action configured with:

  • Access Selection Method: By Identity
  • Identity: $.trigger.launchedBy.id
  • Access Types: Entitlements only (uncheck access profiles and roles)

Assuming the action keeps its default technical name getAccess, the results are available at $.getAccess.accessItems, with each item containing id, name, and type.

Create an array-type Form Input in the form and use it as the source for a Select field. In the Interactive Form action, map the Get Access output:

  • Array Value: $.getAccess.accessItems[*].id
  • Array Label: $.getAccess.accessItems[*].name

After the user selects and submits, the workflow continues with the selected entitlement IDs available in the form data for your post-submission logic.

Get Access returns a maximum of 250 access items, and a Select field populated through a Form Input displays only the first 100 values. This design works best when users do not hold large numbers of entitlements.

Get Access also supports a separate By Search Query mode, but that searches for matching access objects rather than starting from the access held by a specific identity. The action does not provide a way to combine By Identity with an arbitrary source filter in the same step. If you need to retrieve only the launching identity’s entitlements from a particular source, an HTTP Request calling the Search API with more granular filtering would be the fallback.

5

@nmuthusamy

You can achieve this using a Launcher + Dynamic Form + Workflow approach.

  1. Identify the logged-in user

    • In a Launcher form, you can capture the requester’s identity using the workflow context (requestedBy) or identity attributes available in the form/workflow.

  2. Retrieve the user’s entitlements

    • Use a Dynamic Field in the form that calls a Workflow or API to fetch the current user’s entitlements.
    • Alternatively, use the Search API or Identity APIs within the workflow to retrieve all accounts and entitlements assigned to the logged-in user.

  3. Display entitlements in the form

    • Populate a dropdown or multi-select field dynamically with the returned entitlement list.
    • On form submission, pass the selected entitlement(s) to the workflow for further processing.

Recommended approach: Use a Workflow-backed dynamic form field to fetch entitlements for the logged-in user dynamically. This ensures the user only sees their own entitlements and avoids maintaining static lists.

6

In this case, the worflow waits inherently until the form is submitted, can it be fire and forget - I mean can a workflow fire a form and end its execution?

7

Hi @nmuthusamy ,

Good question — but no, out of the box a workflow’s Form step is blocking by design. When the workflow hits the Interactive Form step, it pauses and waits for the user to submit before it moves on to the next step. There’s no setting to just fire the form and walk away in the same workflow.

If you want that decoupled “fire and forget” behaviour, here’s what I’d suggest:

  1. Split it into two workflows. Let the first workflow just launch/send the form and then end — its job is done. Then set up a second workflow that’s triggered off the form submission event itself (similar to how SailPoint recommends handling access request approvals — end the first workflow and pick things up in a new one triggered by the decision event). That second workflow picks up the submitted data and does the actual processing.
  2. Or flip the trigger entirely — since you’re already calling the Forms API directly from your custom UI, you could have the form submission itself call the workflow, instead of having the workflow launch the form. That way the workflow only starts after submission — nothing to wait on at all. This is probably the cleanest fit for your original use case.