Hi Guys,
We have created a form for special ad hoc resignations, and it is important to us that only certain identities can view and fill out this form. Is there a way to configure this?
The Form and Workflow have already been created.
Thanks in Advance
Yes, this can be achieved using an Interactive Trigger. Instead of exposing the form to everyone, configure the trigger so that only the required identities (or a governance group) can launch and submit the form. This ensures only the intended users receive access to the form and can initiate the workflow
Hi @AHKG022,
Use an Interactive Trigger in your workflow and attach the workflow to a Launcher.
When you create a launcher, SailPoint creates an entitlement with the launcher’s name. You can provision this entitlement only to the users who need access to the form.
The form can then be launched directly from the Launchpad.
@AHKG022 Since your Form and Workflow are already created, the main thing you need to control is who can launch or see the workflow/form.
If you are exposing the workflow through a QuickLink, the easiest approach is to put the restriction on the QuickLink itself. You can configure the QuickLink so that it is available only to specific users, populations, roles, or users who meet certain conditions.
For example, if only the HR team should be able to submit a special ad-hoc resignation, create a population or use an appropriate capability/role to identify those HR users and restrict the QuickLink to them. Other users will then not see the option in the UI.
If your requirement is more complex—for example, HR can submit the form, but only for employees within their own department—then you should also add validation inside the workflow. This is important because hiding the QuickLink controls visibility, while workflow validation provides an additional authorization check before processing the request.
So, in simple terms:
QuickLink restriction → controls who can see/open the form.
Workflow validation → controls whether that person is actually allowed to perform the action.
For sensitive actions like resignation/termination, I would recommend using both, rather than relying only on hiding the form.
Hi Pankaj,
Thank you for your response. My question was specifically related to ISC. As far as I understand, QuickLinks are a feature that is available only in IdentityIQ. Could you please confirm if that is correct?
Hi Pucha,
this helped! Thank you!
Hi Selvasanthosh,
this helped! Thank you!
@AHKG022 Yes, Its for a IIQ only.
Welcome to the SailPoint Developer community @AHKG022.
Access is not restricted directly through the Interactive Trigger.
When you create a Launcher, SailPoint automatically creates an entitlement for it. Assign that entitlement only to the users who should be able to view and submit the form from the Launchpad.
As @selvasanthosh correctly explained, the recommended approach in ISC is to control access through the Launcher entitlement.
If you want a decent presentation on the interactive workflows / forms / launchers, I did a presentation at Navigate2025 on this:
Found here: Watch Navigate 2025 Sessions On Demand | SailPoint
under the title: Real-world impact of workflows
I go into the configuration and details in medium depth for this very “immediate termination” flow.
Yes. The recommended approach is to control access to the workflow, not the form itself.
Options:
If the form is a standalone Workflow Form, there is currently no OOTB form-level ACL that directly limits who can view the form URL. The common pattern is to restrict workflow initiation to an authorized population and validate the user’s eligibility at the start of the workflow, terminating the process if they are not authorized.