Workday Employee/Contingent Conversions - Workday Connector

[BrandonLucas_BF]

I am posting this in the community in hopes that someone else who has done a Workday integration has also encountered this issue and has advice on how to deal with it.

Workday is our source of truth. Very frequently, we are seeing that during worker conversion events from contingent to employee or vice versa, the Workday connector will get a little bit confused about which record to pull in to Saviynt. We have found through analysis, that incremental imports, which we run throughout the day, will pull in whichever workday record was touched last (either contingent or employee) since the last incremental user import. 

This results in confusion where a contingent worker transitions into an employee role, Saviynt detects this change and executes rules to move their access, but then in the back end in Workday, there is still work being done on their old contingent employee record, even though it is not active. On subsequent imports, Saviynt may detect that the older inactive contingent record was changed, and then update their user record in the Sav users table reverting them back to contingent status, which in that scenario could mean that they lose access or are disabled completely. This issue can also happen in reverse when going from employee > contingent.

We need to work out a connector configuration that only pulls in the current active record in the scenario where a user has both a contingent and employee record in Workday. My understanding from Workday is that the user has the same employee number in their database, but different Workday record IDs. In Saviynt, the users primary key is their employee number, so this causes the conflict. However, that is the way it must be designed otherwise we would have two records for the same person in Saviynt - one for employee and one for Contingent status.

I believe this is a common problem because I found references to this in Azure AD documentation when using Workday as a source of truth for provisioning there. Has anyone dealt with this scenario before?

https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/workday-integration-refere...

[sk · Accepted solution]

We had similar use case in our environment where we faced same issue. But in our case both contractor and employee records come as active because we employee record will be created before hand. So in full import we use to get contractor record and in future hire import we use to get employee record. 

Because of that User data use to flip b/w Employee vs contractor. Which use to trigger mover certification for such users on each aggregation.

We handled this use case using in-line preprocessor where we implemented a logic to skip employee record until hire date becomes current.

[BrandonLucas_BF]

This is a great idea and likely will work for us. Meeting with our Workday integration team to discuss. If this is a solution, I'll come back and mark with full details.

[BrandonLucas_BF]

Marked this as the solution. We were able to identify some patterns in the data coming from Workday that indicates this condition and we used user-preprocessing to drop the undesired data during import.

[rushikeshvartak]

Prefer creating separate connection for employees & contractors 

[BrandonLucas_BF]

I've done this on a past deployment at a different employer, but this won't work in this environment. The reason being that in Workday during a contingent/contractor conversion to hire/employee scenario, or vice versa, the user will keep the same username correlating to one user record in Saviynt. With different connections for employees and contractors we could separate when we run the imports and different logic for each and so on. However, we'd simply be recreating the same problem a different way because the end result is the same record being updated at incorrect intervals in Saviynt due to the way Workday API presents the data at the source.