Workday: Incorrect Termination Record Being Aggregated

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

We are trying to resolve the problem with the Workday connector where it can incorrectly bring in the wrong termination record for a user. There is documentation around potential options, but one is not working, and we aren’t sure we fully understand what is required for the second option.

Reference Documentation:

What we have tried:

  • splitPastTerminationOffsetBy- This is not working for us because our Past_Termination_Offset is set to 1095 (i.e. 3 years) and splitting it still puts multiple records for the same person in the same side of the split and it is bouncing back and forth on which record it wants to pick.

  • disableMultipleWorkerRecords - We set this attribute to true, but it also is not resolving the problem. This documentation appears that more has to be done to use this than just the setting the attribute to true, but the documentation isn’t clear on what else might need to be done. We have noticed that OOTB, there is an xpath for CHECK_LASTEST_WORKER_RECORD, but not LATEST_WORKER_RECORD. We also are not clear if using this attribute will prevent us from retrieving future dated records or not.

Does anyone know how to make the disableMultipleWorkerRecords attribute work as described in the Knowledge Base Article, or have any suggestions on how to ensure that aggregation is always picking the most recent terminated worker record?

We do not want to reduce the Past_Termination_Offset because that will start deleting identities that we need to have in order to correlate accounts to for clear and concise auditing and administration.

2

We are having similar situations.

We have set the “checkDeletedDisabled”: “true”, parameter to help prevent deletions. However, we noticed an Identity that was deleted because they were a rescinded account.

I believe this link may fix issues with rescinded account deletions. Rescinded and Corrected User Records (sailpoint.com)

[
    {
        "op": "Add",
        "path": "/connectorAttributes/deleteRescindCorrectedLink",
        "value": "true"
    }
]

However, it makes me wonder, what other situation might cause a deletion.

We are also running into an issue where there are multiple records having the same file number, same user, but different organizations. Where they usually don’t have two active accounts, but it is possible where someone is a contractor as well as an employee and may be doing part time work while also having a full time job.

While I’m not trying to take over your post or diminish what you are stating, I also think that when Identities shouldn’t be deleted, how can we make sure IDN Identities are not deleted for all operations / aggregations, but also be able to identify other possible issues with multiple records and how to handle them appropriately and to understand where issues may arrise.

Example. We found where someone was terminated earlier this year. They also had another account where they were recently terminated for a different job / record and we were aggregating the data between the two of them with altering changes. One aggregation seems to be setting a lifecycle state for a old account that would be deleted across systems, where then the next aggregation it would be grabbing the data for the other record and applying a lifecycle change and entitlement change that was associated to accounts that were recently terminated. If this was an active account, they would more than likely be created, deleted, created, delete and so on.

Hopefully these parameters I have shared will help you. I really think a comprehensive document would be helpful on what issues you can run into with having multiple records and the best practice of how to handle them.

Personally my view is that every organization or every type of employee type should have a unique filenumber. If they are a contractor, use the same file number but with a “c” in front, or something that makes them unique, but that you can easily associate with the same person.

3

Update: This solution only worked after the FIRST aggregation. Subsequent aggregations continued to be problematic flip flopping the termination record grabbed for a worker.

We believe we may have found a solution that works:

  1. set disableMultipleWorkerRecords to true on the Workday source in IDN
  2. In Workday, create a calculated field called LATEST_WORKER_RECORD with data type of T/F (this field needs to return a Y for the latest record for a worker)
  3. Add LATEST_WORKER_RECORD__c to the Workday account schema in IDN
  4. Add CHECK_LATEST_WORKER_RECORD to the Workday account schema in IDN if it is not already there. The XPath for this should already be present, but if not, it should be set to:
    ns1:Worker_Data/ns1:Integration_Field_Override_Data[ns1:Field_Reference[ns1:ID[@ns1:type='Integration_Document_Field_Name']='LATEST_WORKER_RECORD']]

Note: The problem only seems to surface with full aggregations, and not from single account aggregations. This can be helpful to know if you spot a problem and want to fix an individual without running a full aggregation or if you don’t have your calculated field ready in Workday yet.

4

Here is a workaround that we found to work. We left Steps 1-4 in as we think that is how it’s intended to work even though it doesn’t. Step 5 is what resolved the problem for us.

  1. set disableMultipleWorkerRecords to true on the Workday source in IDN
  2. In Workday, create a calculated field called LATEST_WORKER_RECORD with data type of T/F (this field needs to return a Y for the latest record for a worker)
  3. Add LATEST_WORKER_RECORD__c to the Workday account schema in IDN
  4. Add CHECK_LATEST_WORKER_RECORD to the Workday account schema in IDN if it is not already there. The XPath for this should already be present, but if not, it should be set to:
    ns1:Worker_Data/ns1:Integration_Field_Override_Data[ns1:Field_Reference[ns1:ID[@ns1:type='Integration_Document_Field_Name']='LATEST_WORKER_RECORD']]
  5. Set the account.filterString on the Workday source. Note: the reason we are using “starts with” is because IDN is finicky and sometimes it brings it in as a Y (which is what Workday sends), and sometimes it displays as a “Yes” on the account. We don’t know exactly why that happens, but at this point, we are just happy we have a path forward.
[
    {
        "op": "add",
        "path": "/connectorAttributes/account.filterString",
        "value": "!( LATEST_WORKER_RECORD__c.startsWithIgnoreCase(\"Y\") )"
    }
]
5

Although the solution that I am replying to is the solution that we are moving forward with, it is worth noting that a SailPoint contact gave guidance that we should consider setting “Eligibility Criteria” on the connector for only bringing in specific records. For more details on this, please check the doc Support for Filtering Using Eligibility Criteria

The idea of using this is that the filtering would be done at the connector level instead of the ISC layer and might perform better, but the filtering concept is the same.

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.