Organizations need a fast, secure, and automated way to immediately terminate identities in the event of an emergency. This session introduces a SailPoint Identity Security Cloud Workflow designed to instantly disable user access by changing their Lifecycle State. Originally built to be triggered through third-party API calls, this solution has been enhanced to leverage SailPoint’s Interactive Forms, enabling direct execution from the Launchpad without the need for external integrations or intervention by a user with elevated permissions.
This demonstration will explore the workflow architecture, key automation steps, and how this process eliminates administrator intervention, ensuring faster, more secure offboarding while minimizing security risks. Whether you are an engineer, administrator, or security professional, this session will provide insights into workflow automation, best practices, and real-world applications.
How do you handle the risk that SailPoint might later change the LCS and reactivate the account? (For example, if the calculated LCS differs from the one calculated the day before)
Especially when you have different LCS used to easily notify manager of the coming expiration of a user ? (for Contractors Use Case)
In our context, we chose to use a dedicated LCS Red Button and using transform we block all automatic updates except to the inactive LCS.
If needed, identity can be unblocked using manual action into ISC.
I’m interesting by your feedback on this specific point.
In our implementations with clients, we emphasized that this immediate termination flow is only a small part of the complete termination process. This process was designed to go hand-in-hand with how ISC handles manual LCS changes:
The manual setting is applicable as long as the underlying value on the source doesn’t change. When the value on the source changes, the Lifecycle State field gets reset to an automatic value.
The expectation is that this workflow will immediately deprovision the most critical access, and that eventually, HR will update the termed user’s data in the auth source. Once the HR data is updated and ISC runs an aggregation, we would want the LCS to change to the standard “inactive” LSC so that the identity will flow through the complete termination process. Something like the flow below has been the desired process in our implementations:
Active (automatic) → Immediate Term (manual) → Inactive (automatic)
Thank you for sharing this- it’s exactly the kind of solution we’ve been looking for. I built a similar Interactive Form and workflow, however, when I run it, the identity is not being terminated as expected.
Could you suggest possible reasons for this behavior or share any best practices for troubleshooting? I’d appreciate any guidance on how to verify the configuration and ensure the workflow executes correctly.
PS: I double checked both the Interactive Form and Workflow and don’t see anything that could case an error.
Hi @kkilafwasru Thanks for demonstrating the capabilities of forms and workflow. I have one concern in this approach. I am wondering name passed from form is not a unique value to use in get Identity. It could return multiple identities. Is it possible to pass the identity id of selected user from the form itself?
Hi @sanumathewipg0207
While building the workflow I ran to a similar issue and get identity step returns only one identity value. If you have multiple identities with same first and last names, it’s going to pull only one of them and there’s limitation to identity proofing when initiating the workflow. Therefore, to resolve this, instead of pulling identities with display name in the Form, you can select uid/identity id/employee number or any other attribute that’s unique to the identity.
Also, for identity proofing step, it is possible to pass identity id/name/ or any other info like department number from the form. To do that in the interactive message step just add inline variable depending on your configuration (e.g. {{$.hTTPRequest.body[0].attributes.identityId}}). Let me know if you have any other questions!
Do you have to use HTTP requests? Or could you just reference prior steps - back to the formData itself? i.e. $.interactiveForm.formData.identityName
Perhaps I missed it in the video but how do you granularly provide access to this form? I would like to allow for HR to be able to run it, but don’t want to give them ORG_ADMIN.
Any recommended workarounds for cases where this is to be used for disabling the account because the HRIS process sometimes takes too long and we can’t garauntee it will be disabled on the next aggregation? Don’t want the Lifecycle State to reset itself simply because the Auth Source is on a 1-hour aggregation and the source system needs longer than 1 hour to process.
Yes, we have to reference http requests. formData itself will not pull all the info you need for next steps.
I don’t think it’s mentioned in the video but we don’t have to grant ORG_ADMIN to HR at all. When you create the form in the first step SP creates launcher entitlement automatically and you can assign this entitlement to HR through role.
This is advanced workflow but once you understand how it works you can easily customize it. That being said you can create the form and change workflow where accounts will be disabled instead of terminating identity. Or you can just build workflow where all access will be stripped away once LCS state goes inactive state, no need to wait for next aggregation.
