The requirement is that when a user is terminated, their access should not be removed immediately. Instead, their access should remain active for 7 days from their end date (for example, if the end date is today, access should continue for the next 7 days). After the 7-day period is completed, their access should be removed.
To achieve this, we need to first identify the source, then retrieve the associated accounts, and from those accounts identify the corresponding identity. Based on the identity’s end date (for the user being terminated), the workflow should perform the above logic.
For this scenario, an exact workflow needs to be created to handle the process.
The above use case can be achieved either by creating a new lifecycle state or by modifying an existing lifecycle state to include the 7-day condition.
Is there any specific requirement that necessitates using a workflow for this
You can create one new attribute in Identity profile as extendedEndDate. Compare this attribute with the actual end date of the user. If the value is 7 then change the cloud lifecycle state to Terminated.
And configure the workflow to remove the accounts or you can use lifecycle state also to remove the accesses.
For this usecase what you can do is to create a Lifecyclestate called for example leaved_after_sevenday and in your Lifecyclestate transform you can add logic to move on this state automaticlly if current date is greater or equal to enddate+7 day.
You can then use the workflow with trigger Identity attribute change and filter for this new lifecyclestate.
Then you have choice to manage access (remove) by using a microcertification campaign or combine get access or remove access.
As per our requirement, we do not need to use the identity profile or lifecycle state, and the solution should be implemented entirely through a workflow. But, is there any possibility of using a rule to achieve this?
Add a grace period date attribute (termination date + 7 days) in the workflow, schedule a daily task to evaluate it, and use a rule to remove roles and access once the grace period is completed.
for this i agree with other colleagues, at the least you will need to have an identity attribute created to trigger the workflow.
I am curious to know the reason why would you want to achieve this requirement with workflows only when SailPoint has now launched the out of box functionality to remove all access and delete accounts based on identity state.
This will then mean that id you can have one new lifecycle state and you configure it as long_term_inactive, then you should be able to achieve all the functionalities automatically or may be i am missing something here as we have not moved this logic from workflows to identity states yet.
But i think exploring the identity states could be easier as for workflow then you will have to ensure that there is a proper monitoring in place in case the workflow gets failed where as identity state could be easier option to manage in my opinion.
I am not sure the reason behind this decision, but I can say this is not a good approach. Workflows should be used for carrying out secondary operations, and LCS related activities should depend on LCM which is the core feature of ISC
Agreed, WF is wrong approach here. We have almost exact same requirements and have a separate lifecycle state to denote the 7d period before being a full leaver.
@Snehamani If your requirement is only on the access side or the account status also? For this without workflow also you can achieve it via
1- Create another lifecycle state(ex delete)
2-For your cloud lifecycle transform update the logic such that it moves to delete state after 7 days of termination(you can use date math transforms here)
3- SailPoint has a feature of remove all access in LCS state enable that
As a final query, has your CISO really signed off on not removing access immediately on termination? I can only think of 1 scenario (UK legislation) when access needs to remain after termination and that is for payroll services/payslips
Hi @Snehamani , for this requirement, you need to create two lifecycle states: Terminated and RemoveAccess.
When a user reaches their end date, the lifecycle state should be set to Terminated.
When the end date is 7 days away, the lifecycle state should be set to RemoveAccess.
You can implement this logic using a transform to evaluate the conditions and assign the appropriate lifecycle state. Then, configure the required actions for each lifecycle state accordingly.