How to pass Interactive Form data submitted through a Launcher to the Manager for review before approving an Access Request in SailPoint ISC?

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

Hi Everyone,

We are implementing an access request process in SailPoint Identity Security Cloud (ISC) and need some guidance on handling Interactive Forms within a workflow.

Our requirement:

  1. A requester launches a workflow using a Launcher.
  2. The requester fills out an Interactive Form with the required information.
  3. The submitted form data should be sent to the requester’s manager.
  4. The manager should be able to view the complete form data while reviewing the request.
  5. The manager should then approve or reject the access request based on the submitted information.
  6. After approval, the workflow should proceed with access provisioning.

What we have implemented:

  • We created a workflow with multiple Interactive Forms.
  • The requester completes the form before the access request is submitted.
  • We dynamically capture the generated formInstanceId.
  • We pass this formInstanceId in the requestedItems payload of the Create Access Request API.

Issue / clarification needed:

We want the manager to see the actual form data submitted by the requester as part of the approval process. We are currently facing issues with the form handoff, including errors such as:

  • Form is not configured on entitlement - getting error “FormInstance handoff missing”
  • Form is configured on entitlement - getting error “Required form submission for entitlement.”

Questions:

  1. Is passing the dynamically generated formInstanceId through the Create Access Request API the correct approach?
  2. Is there a recommended way to associate the workflow Interactive Form instance with the entitlement’s configured access request form?

Any examples, documentation, or guidance on the recommended workflow design would be greatly appreciated.

Thanks in advance!

2

Hello Bapu. Yes, passing formInstanceId through POST /access-requests/v1 is supported. Both errors suggest a form association or handoff issue.

I would suggest checking these:

  1. Entitlement: Admin > Access > Entitlements > Actions > Edit > Access Requests. Enable Allow Access Requests, turn on Require Access Request Form, and select the intended form.
  2. Form instance: verify that its formDefinitionId matches the form attached to the entitlement, and confirm the form was submitted successfully. The docs note a definition that does not match the configured formDefinitionId, a missing instance, or unreadable instance data can fail the request during asynchronous processing even when the API call returns success.
  3. API: pass the formInstanceId on the matching GRANT_ACCESS item in requestedItems (or requestedForWithRequestedItems.requestedItems for the nested shape). Each item supports one instance, so consider consolidating multiple forms into the one form on that entitlement if the manager needs all the information together. Completed answers come back in the form object (form.formData), and the attached form is included in the review details.
  4. Approval: under Reviewing Access Requests on the entitlement, select Require Approval, choose Reviewer, and add Manager so the requester’s manager reviews it.

For your step 6: once the request is submitted, ISC handles approval and provisioning natively, and the Launcher workflow does not wait for the decision. Keep the post-approval provisioning out of that workflow. If additional actions are needed after the decision, use a separate workflow with the Access Request Decision trigger.

I would first request the entitlement directly through Request Center and verify that the manager can see the submitted answers. If that works, the native configuration is functioning. Then test the Launcher-generated formInstanceId separately, compare its formDefinitionId and submitted data against the configured form, and check the access request status for processing failures.