Lifecycle State Transform

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

I implemented the below transform to set the LCS on our non-employees. I tested with an account and set the end date in the source to 04/14/2026 and it disabled the AD account this morning at 8:00 am eastern time but I was looking at another account that had the same end date but the LCS was still active. Trying to figure out why it didn’t change the LCS at 8:00 am

{

"id": "23396ad4-568f-492d-95ef-6672d479e2ac",

"name": "Calculate_NonEmployee_LifecycleState_SB",

"type": "dateCompare",

"attributes": {

    "firstDate": {

        "type": "dateMath",

        "attributes": {

            "input": {

                "type": "dateFormat",

                "attributes": {

                    "input": {

                        "type": "reference",

                        "attributes": {

                            "id": "Normalize End Date"

                        }

                    },

                    "inputFormat": "MM/dd/yyyy",

                    "inputTimeZone": "America/New_York",

                    "outputFormat": "ISO8601"

                }

            },

            "expression": "+32h"

        }

    },

    "secondDate": "now",

    "operator": "gt",

    "positiveCondition": "active",

    "negativeCondition": "inactive"

},

"internal": false

}

2

Hi @dpowers1

From my understanding, 1st account changed because you changed its end date that triggered event based processing. 2nd account end date was already set with no source change. For this reason scheduled job skipped it as there were no changes detected. Can you try to run manual process Identity on the 2nd account to force re evaluation.

Thanks

3

I did do a manual process of the account and it disabled it. So would there be something in the transform that I need to change so it will work for both situations

4

what was the identity state of this account/identity that you had to manually process?

5

Implementing Time Based Processing

6

The identity state was Active and the LCS was Active

7

Ok so here is my transform for the Next Day Processing, should I change the transform that calculates the LCS. So a user that has an End date of 04/15/2026, the account should process at 2026-04-16T12:00Z {

"id": "0acc8c7e-4971-41fe-9af3-f3b7a0631938",

"name": "ENDDATE_SB",

"type": "dateMath",

"attributes": {

    "input": {

        "type": "dateFormat",

        "attributes": {

            "input": {

                "type": "accountAttribute",

                "attributes": {

                    "sourceName": "ARHSB-Passport Database",

                    "attributeName": "End_Date"

                }

            },

            "inputFormat": "MM/dd/yyyy",

            "outputFormat": "ISO8601"

        }

    },

    "expression": "+36h"

},

"internal": false

}

8

Or can I leave this as is and if an aggregation is ran at 8:00 am on the source then should it process the identity

9

I would suggest apdating Calculate_NonEmployee_LifecycleState_SB transform by adding “requiresPeriodicRefresh“ : true flag and test it. This will re evaluate every identity.

{
  "id": "23396ad4-568f-492d-95ef-6672d479e2ac",
  "name": "Calculate_NonEmployee_LifecycleState_SB",
  "type": "dateCompare",
  "requiresPeriodicRefresh": true,
  "attributes": {
    "firstDate": {
      "type": "dateMath",
      "attributes": {
        "input": {
          "type": "dateFormat",
          "attributes": {
            "input": {
              "type": "reference",
              "attributes": {
                "id": "Normalize End Date"
              }
            },
            "inputFormat": "MM/dd/yyyy",
            "inputTimeZone": "America/New_York",
            "outputFormat": "ISO8601"
          }
        },
        "expression": "+32h"
      }
    },
    "secondDate": "now",
    "operator": "gt",
    "positiveCondition": "active",
    "negativeCondition": "inactive"
  },
  "internal": false
}
10

Apparently IdentityNow doesn’t support requiresPeriodicRefresh because I add it and then it strips it away. I have set my authoritative source to do an aggregation every hour, I would assume that triggers an identity refresh

11

requiresPeriodicRefresh is a top level property on dateCompare.
In this case, I would suggest to leave LCS transform as it is and add a nextProcessing transform and test it.

{
  "name": "ENDDATE_SB",
  "type": "dateFormat",
  "attributes": {
    "input": {
      "type": "dateMath",
      "attributes": {
        "input": {
          "type": "dateFormat",
          "attributes": {
            "input": {
              "type": "reference",
              "attributes": {
                "id": "Normalize End Date"
              }
            },
            "inputFormat": "MM/dd/yyyy",
            "inputTimeZone": "America/New_York",
            "outputFormat": "ISO8601"
          }
        },
        "expression": "+32h"
      }
    },
    "inputFormat": "yyyy-MM-dd'T'HH:mm",
    "outputFormat": "ISO8601"
  },
  "internal": false
}
12

I added a transform to the next day processing. Will wait and see what happens tomorrow at 8:00 am

13

Any changes on this? Thanks

14

I had 4 accounts in our Sandbox that had an end date of yesterday, and all 4 accounts got disabled this morning at 8:00 am. Here is what the identity attributes look like for one of the users

image
image568×119 2.85 KB

15

Sounds good. If this resolved your issue could you please mark my answer above as the solution? That way, others can more easily find the actual fix. Thanks