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.
