Prevent inactivity rule from inactivating users returning from leave (ISC)

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hey community,

We currently have a lifecycle transform in SailPoint Identity Security Cloud (ISC) that checks user inactivity (last login). If a user hasn’t logged in for 60 days, they’re moved to an Inactive state. This is working as expected.

We also integrated an On Leave indicator from our HR source (Workday) using a simple 0/1 flag, and that piece is working too.

The problem we’re trying to solve is the return-from-leave scenario: a user can go on leave with a last login date that’s already far beyond the 60‑day threshold (e.g., 1 year ago). When they return and the flag flips back, they immediately fail the 60‑day inactivity check and end up in Inactive, even though they should return to Active.

To address this, we’re exploring an identity attribute that stores a date we can compare against (e.g., a “return from leave” date). We tried creating a transform to store “today’s date,” but with our current logic the date gets overwritten based on the flag changes (0 ↔ 1), which defeats the purpose.

{
“name”: “On Leave Flag”,
“type”: “static”,
“attributes”: {
“today”: {
“type”: “firstValid”,
“attributes”: {
“values”: [
{
“attributes”: {
“inputFormat”: “yyyy-MM-dd”,
“outputFormat”: “MM/dd/yyyy”,
“input”: {
“attributes”: {
“begin”: -1,
“end”: 10,
“input”: {
“attributes”: {
“expression”: “now-10h”,
“roundUp”: false,
“requiresPeriodicRefresh”: “true”
},
“type”: “dateMath”
}
},
“type”: “substring”
}
},
“type”: “dateFormat”
},
“01/01/2036”
]
}
},
“onleave”: {
“attributes”: {
“values”: [
{
“attributes”: {
“sourceName”: “Workday”,
“attributeName”: “ON_LEAVE”
},
“type”: “accountAttribute”
},
“blank”
]
},
“type”: “firstValid”
},

    "value": "#if($onleave=='1')$today#elseif($onleave='0')01/01/2036#{else}01/01/2036#end"
},
"internal": false

}

Has anyone implemented a reliable pattern to ensure users returning from leave are moved back to Active without being immediately caught by an inactivity-based inactivation rule?

2

You can try two options from my analysis:

  1. Create a custom attribute to store the previous state. Tranform with below logic like this
    If($HRaccountAttr!=$IdentityAttr)${IdentityAttr}#elseif($previousStatus!=‘blank’ && $previousStatus!=$HRaccountAttr)$previousStatus#{else}${HRaccountAttr}#end"
    And have a trigger in workflow only when status changes from onleave to Active, then update the last login to the return date.

  2. We currently have a lifecycle transform in SailPoint Identity Security Cloud (ISC) that checks user inactivity (last login). If a user hasn’t logged in for 60 days, they’re moved to an Inactive state. This is working as expected.

Try to exclude the identities in this transform with OnLeave is 1.

Hope this helps!

3

Great suggestion, however, we are unable to update the last login on Entra, it is an uneditable field

update the last login to the return date.

4

Hi @cryan3

Based on your description, the key difference between the “return from leave” case and a user who simply hasn’t logged in for 60 days is the current lifecycle state.

Here’s how to look at it:
-If a user hasn’t logged in for 60 days, their lifecycle state should be set to Inactive. In this scenario, the user’s current lifecycle state would typically be Active, which makes this a valid case of inactivity.
-For a user who has been on leave for a year, their lifecycle state would be On Leave. When they return, the leave flag will switch to 0/1, triggering the 60‑day inactivity evaluation. However, at that moment, their current lifecycle state is still On Leave, not Active — and this is the differentiating factor.

In summary:
When checking for 60‑day inactivity, the logic should also validate the user’s current lifecycle state.
-If the lifecycle state is Active, then the inactivity condition is legitimate → set LCS to Inactive.
-If the lifecycle state is On Leave, then this is a return‑from‑leave scenario → do not treat it as a 60‑day inactivity case.

5

In that case, one of the options that i can think is:
You need to have one more attribute which captures todays date when status changes from On Leave to Active. And in your transform

We currently have a lifecycle transform in SailPoint Identity Security Cloud (ISC) that checks user inactivity (last login). If a user hasn’t logged in for 60 days, they’re moved to an Inactive state. This is working as expected.

You need to update logic:
If user inactive for 60days, then check previousstate value and date value attribute that you created. If the date value is lessthan 60days, you shouldn’t mark the identity to inactive. If it is more than 60days, then change the identity status to inactive.
It looks kind of complicated, but with the scenario explained above, these are my thoughts.
Thanks

6

@rpriya that is a good logic but there are few edge cases that doesn’t cover in this logic.

When user comes back after long leave, their status will become Active and as per the logic explained, user will be moved to inactive state.

7

@JagadeshMuchumarri, when a user returns from an extended leave, a specific indicator switches to 0/1 as mentioned above, which triggers the LCS transform evaluation. At that moment, the user’s current lifecycle state is still On Leave. If an additional condition checks whether the lifecycle state is not On Leave before applying the 60‑day inactivity rule, then:
– If LCS ≠ On Leave and the user meets the 60‑day inactivity criteria, set LCS to Inactive.
– Otherwise, retain or set the LCS to Active

8

This use case has multiple scenarios:

  1. When user not logged in 60 days.
    a. When user LCS is Active
    b. When user is on Long Leave
    c. When user comes back from long leave
    i. User comes back and wants to login within 60days.
    ii. User comes back and login after 60days.
  2. When user logs in regularly.

Please confirm if the above recommendation covers all the cases?