Search logic and transform logic miscalculating

[mpotti (Mark Potter)]

Hello Everyone,

I am wondering if anyone has run into an issue where using the date frame logic for search and transform where when the calculation takes place it is not doing the proper calculation?

In my use case I have the following transform logic:

{
    "id": "REMOVED",
    "name": "Transform - Calculate PreHire LifeCycleState",
    "type": "dateCompare",
    "attributes": {
        "requiresPeriodicRefresh": "true",
        "firstDate": {
            "attributes": {
                "expression": "now+1d/d",
                "roundUp": false
            },
            "type": "dateMath"
        },
        "secondDate": {
            "attributes": {
                "input": {
                    "attributes": {
                        "values": [
                            {
                                "attributes": {
                                    "attributeName": "Hire Date__c",
                                    "sourceName": "Workday Production"
                                },
                                "type": "accountAttribute"
                            },
                            "2021-08-06"
                        ]
                    },
                    "type": "firstValid"
                },
                "inputFormat": "yyyy-MM-dd",
                "outputFormat": "ISO8601"
            },
            "type": "dateFormat"
        },
        "operator": "GTE",
        "positiveCondition": "active",
        "negativeCondition": "prehire"
    },
    "internal": false
}

The goal of this transform is move a user to active status 24 hours before the start date. The behavior that I am seeing is that if a user starts on 11/01/2024 it is moving to active status on 10/30/2024. There appears to be a +12 hours added to the calculation.

I also have a process outside of SailPoint that is calling the Search API using this following search filter

searchModel.Query.Query = "attributes.startDate:[now TO now+1d]";

The goal of this process is to send the end user an email 24 hours before their start date. Again we are seeing the same behavior where the email is being sent on 10/30/2024 if the start date is 11/01/2024.

We think what is happening is that when the job runs it is converting it to UTC time. Which is what is putting off our calculations and why we are not seeing the expected behavior.

I have updated my outside of IdN logic to code a date based on the CT. But I am not sure how to update the transform to add a day - 6 hours from its calculation. Any ideas how to set up this calculation?

[ipobeidi (Ivan Obeidi)]

To solve that you neet to create a attribute with the sufix datetype. that way it will work with the date search.

Normally endate and startdate have this already.

ex: attibuteName AdPasswordlastsetdatetype

Also you need to consider the timezones in you date calculations.

[neeraj99 (Neeraj Nautiyal)]

I think the query you are using may not be returning the data correctly as you are doing a search based on now+1d. Can you change it to 10 days and see if same thing happens like additional 12 hours? If this time it returns more identities or less then try configuring the attribute like this.

Search joining date similar to created in ISC

Hi @ggregory199 So in order to achieve this use case, you will have to create a attribute which should have “DateType” at the end. Ex: joiningDateType (Techinical Name) Once you have the attribute created like above, create a transform as well. This is to make sure that the date coming from source matches the format of now. See the below attached Code snippet. P.S. if you have time also coming in please update the Output format accordingly. Reference document for date-time that sailpoint s…

[mpotti (Mark Potter)]

Thank you both for the replies. The issue was the calculation was converting to UTC. I updated the transform to be now+1d-6h/d to take my time zone into account in the calculation.

So what I was able to discover was the because this process was running at 8pm CST when the value was being converted it was actually 1am the following day UTC time. This was cause the calculation to actually be off by 5 hours thanks to daylight saving time. By adding the -6h ensures that the date is correct for both standard time and daylight time.

After running some test with this updated values the accounts are going active at the correct day now and are no long off due to the time calculation.