1

I'm working on an integration with Workday, and am tracking people by their WID (Workday ID), such as 85bb0669d8ac412582c0a473f7074d79. That WID may be interleaved with WID's from unrelated employers using completely distinct Workday accounts, as well as with IDs (known to be UUID's) from other other (non-Workday) sources.

The only ID source that is not known to be a UUID is the WID.

My standard approach to ensure uniqueness of ID's from various external sources would be to save two fields, external_source (e.g. "workday") and external_id (e.g. "85bb0669d8ac412582c0a473f7074d79"). When combined, these two fields assure uniqueness of person ID's across all sources and employers. But if I can confirm that the WID is in fact a UUID, I can make some desirable optimizations.

I've found no explicit definition of WID in Workday documentation of the WID other than, "The unique identifier type. Each "ID" for an instance of an object contains a type and a value. A single instance of an object can have multiple 'ID' but only a single 'ID' per 'type'. " from https://community.workday.com/sites/default/files/file-hosting/productionapi/Human_Resources/v20/Get_Workers.html

All the samples of WID's I've seen are 32-character hexadecimal strings, matching some non-authoritative articles I've found. I've not found any Workday documentation that spec's that they will always be in that format. They are not formatted with hyphens like a UUID, but could be arranged that way.

So...does anyone have a reference to Workday documentation that specify the contents of a WID? Lacking official docs, does anyone have practical knowledge about it?

David Hempy
  • 5,373
  • 2
  • 40
  • 68
  • 1
    That is almost certainly a UUID with the dashes stripped out. The problem is that, without an official recognition of that fact from Workday themselves, there's no way to know whether or not you can treat it as an actual UUID. They may be generating it in a domain-specific way that compromises its uniqueness. Contact Workday directly and ask them. – Robert Harvey Nov 30 '22 at 15:39

1 Answers1

2

Late to answer, but maybe this will be helpful anyways. WIDs are an immutable, unique ID assigned to an object at the time it's created. In regards to employees:

  • Say John Doe was hired in production, he gets a WID 1234A....
  • If you manually hire John Doe again in a different impl tenant to reproduce some scenario, that John Doe will have a different WID 987B....
  • If you test with John Doe in Sandbox (environment that is a copy from production), Sandbox John Doe will have the same WID in both environments, 1234A....

Pay close attention to which object you are using as your reference object for the WID, here are some "gotcha's"

  • Workers and Workday Accounts are both different objects in Workday and will all have their own WID.
  • A contingent worker who converts to an employee will have a different WID for both the employee and the contingent worker records. If this creates an issue, "Universal ID" is an ID type you can set up that remains the same across a "Person". A candidate, employee, and contractor all would have the same Universal ID, but different WIDs.
sglmr
  • 21
  • 1
  • 5