I have been in a few conversations recently regarding the timeliness when it comes to involuntary terminations. With the frequency of our aggregations and refresh tasks, some higher-ups are feeling that there’s a gap and potentially security risk - so we’ve been discussing what can be done to close the gap.
My thought was that there has to be someone else who is handling involuntary terms in a more efficient way than we are. Currently, if there happens to be an involuntary termination, our Identity and Access Management team will disable an identity’s application accounts, and then wait for the HR system to update their employee record as ‘withdrawn’, while also waiting for our aggregation and refresh tasks to run in order to kick off the leaver feature. The higher-ups are thinking we can greatly improve - thus here I am.
What are some best-practices with handling involuntary terminations? Our system is set up so that we have a source of truth in the form of a CSV file that is aggregated periodically throughout the day (we call it our SAP extract). The SAP extract is basically just a large CSV that has records for every employee - including employment status. Here’s how a normal termination usually works:
HR updates the employment status of an employee to ‘Withdrawn’ in the SAP extract
An aggregation runs on the SAP extract, which then identity mappings are used to update the identity cube with certain details from the SAP extract, notably the employment status
RapidSetup is configured to detect the employment status change, so when an identity goes from ‘Active’ to ‘Withdrawn’, this triggers the RapidSetup Leaver event, and then the identity is offboarded
Our goal is to try and get a process going where when our Identity and Access Management team receives notice of an involuntary term, then the whole leaver process can be triggered manually - for the most part. We’re just not sure what the best practice is to achieve this.
I had some thoughts, but I’m also still relatively new - still working on getting a SailPoint Professional certification. My thinking is we start with HR. They update the SAP extract outside the normal time. We (SailPoint Admins and IAM) can have some kind of form in the UI where we select the user to be terminated, and that form could trigger the SAP extract aggregation and then a targeted refresh for the specific identity.
I know that was a long post and I do hope it made some kind of sense!
Do you disable before you get employee status from HR Source as “Withdrawn” ?
This looks good. Only question here is, do you get the status almost immediately from HR system or is there any delay ?
You can do this of course, using a Quicklink.
The best process which I have implemented and seen in my projects are
Get status from HR or end date, we get to know in advance that a user is going to leave the organization
Once end date is crossed, we mark identity as Inactive and disable all the accounts.
Once end date is crossed 30 days, we delete some accounts, incase if user gets Rehired within 30 days of end date, we just enable the accounts back.
This process we achieve through Leaver lifecycle event.
Along with that, we will have Manual Termination and Undo-Termination Quicklinks, so that in case of any failures or any mistake from HR system, admin can do the damage control.
I am expecting a problem statement in short from you, so that I can give an efficient solution.
Thanks for the quick reply! I’ll answer your questions in order:
for involuntary terms, typically yes, IAM disables the identity’s application accounts before HR source is set to withdrawn.
there is a delay only in terms of aggregation. Our aggregation/refresh schedule is every three hours beginning at 7am, with the last run being at 4pm.
We normally don’t use any termination dates for employees, just the employment status. The hire/termination dates are really just used for audit purposes. As well, we typically keep disabled user accounts for a good long while (a few years, I believe) to satisfy our internal audit requirements.
But it does sound promising using a Quicklink! Our only obstacle would be to have a tight coordination with HR to ensure the employment status in the source file is updated properly before our IAM team triggers the leaver events. I just needed to get an idea on what kind of best-practice process we could put in place without breaking anything.
You seem to be heading in the right direction, and it appears that you have a solid starting point. What you’re describing is a typical use case, especially when dealing with emergency terminations, which are typically managed by IAM administrators.
In fact, you could extend these privileges to the HR team with proper training. This could expedite the emergency termination process. Additionally, you may consider sending a notification to the HR team when an emergency termination occurs, enabling them to promptly update the source record.
That’s good to know! As for HR, they usually notify IAM of the involuntary termination so they can do the disabling portion.
One last question from me, though: since we have the HR file as the source of truth for employment status, when an involuntary termination comes in, would it be good practice to fully aggregate the HR file after HR sets a particular employee to withdrawn? We have about 12.5k employees on this file, so I’m thinking in terms of time and performance impact.
Develop a Quicklink for Termination and Undo-Termination.
You can re-use your existing Leaver workflows.
When HR updates involuntary resigned user status as Withdrawn, nothing will trigger as you have already completed Termination for the same user.
But one possibility is that, what if HR won’t update status as Withdrawn but user is already Terminated, so it should not become active again (Kinda Rehire). You should handle that. HR does make mistakes.
You really need Undo-Termination. What if HR sends the feed with a lot of users status as Withdrawn as a mistake. In my experience, I have experienced once where 1000+ users were marked as inactive by mistake. Thankfully we had Undo-Termination to fix the issue quickly.
I would also advice to have the QuickLink solution (Termination and Undo-Termination) as mentioned by @MVKR7T
This gives more flexibility for your procedures. If accounts need to be disabled as fast as possible than the QuickLinks can be used. Also the HR aggregation can be used when speeds is not that important (when it can wait for the HR aggregation task to run).
Here some extra advice when you develop the QuickLinks:
Make sure a comment is needed when activating the Termination and Undo-Termination
Reduce the QuickLink Population to a small group where this group is properly instructed on how to use and the implications of the QuickLink usage
Adapt the ‘normal’ lifecycle events for Joiner/Mover/Leaver to not trigger for ‘Terminated’ identities
adjust to UIConfig to show the Terminated Status (identityTableColumns/identityViewAttributes)
