Workday Reference ID Data Standard

Intended Audience and Contact Information

Contact	Chief Data Officer, Office of the CIO
Intended audience:	Internal UBC
UDM Domain	All

Purpose

This standard aims to achieve consistency with how identifiers are defined and structured within Workday. Naming of Reference IDs has major downstream impact including:

the ability to manipulate objects and their values programmatically i.e., whether it is possible to access, integrate, and/or automate the management of Workday objects within the UBC application ecosystem, and
maintenance and sustainment of the ID (i.e., how confusing, difficult to remember, and/or outdated the keys become if they are not aligned with best practices).

This standard is to be adhered to with regard to user-defined Workday Reference IDs. Exceptions are listed below under the Dispensation section.

Workday identifier types

Identifier	Definition
Reference ID	A unique ID for an object or field that can be system-generated or user-defined. Enable an integration or a data load to set a unique identifier for a Workday object. Remains constant across all Workday environments – production, sandbox and implementation tenants. Easily human-readable All reference IDs have the ability to be changed/updated. MOST objects and fields will have a reference ID, though there are a handful that do not.
Workday ID (not applicable to this standard)	A system-generated unique identifier for every object and field and cannot be updated/changed. Specific to different Workday environments – production, sandbox and implementation tenants Can prevent integrations from running against the wrong environment

Standard

Reference ID standard

Requirement	Reference ID Standard
Component structure	Within Workday: Must be made up of two components per proposed structure below. External to Workday: Must be made up of three components per proposed structure below.
Allowable characters	alphanumeric characters allowed (i.e., alphabets and numbers). Allowable special characters include: _"underscore" to be used to replace space within a component -"dash or hyphen" to distinguish between different components No other special characters can be used.
Mixed case	Mixed case representation of configuration values is allowed. For example, Agricultural_Equipment_Supplies
Spaces	Must not include spaces. Use _ "underscore" for space.
Numbers	Numbers must be none-zero and positive. Avoid using leading zeros at the beginning of the reference ID e.g., "00PR-1234"
Descriptions	Components must be named without including descriptions. They must be short and concise.
Length of reference value	Specific Workday organization type and/or worktag types must always be of consistent length. Varying lengths for a single type can be confusing and lead to sorting challenges.
Character limit	Where possible, limit the reference ID to no more than 30 characters.

Reference ID types

Reference ID types	Usage
Within Workday	Intended for unique Reference IDs for business objects within Workday.
External to Workday	Intended for uniquely identifying business objects where the system of record is not Workday, and will be used for integration with Workday as well as for pulling data for joins from data lakes.

Within Workday Reference ID structure

The following structure is to be adopted by all business objects where the system of record is Workday. The Reference ID will be made up of two components as shown below.

«component1»-«component2»

	Component1	Component2
Rules	Workday Business Object Name Full_Name or Prefix	Number (non-zero)
	Mandatory	Mandatory
	Alpha only	Numeric only

Note:

1. Foundation Data Model (FDM) element reference IDs will be the same as the codes for the FDM element. For example, a Supervisory Organization code and reference ID is SO10001.

2. Format must be consistent for the business object once selected. For example, the reference ID for Job Classifications is Job_Classification-123.

External to Workday Reference ID structure

The following structure is to be adopted by all external system business objects where the system of record is not Workday, but will be integrated with Workday. Functional teams must be consulted and sign-off on the definition of these Reference IDs.

«component1»-«component2»-«component3»

	Component1	Component2	Component3
Rules	External Business Object Name¹ Full_Name; or Prefix	External System Name System Acronym²	Identifier
	Mandatory	Mandatory	Mandatory
	Alpha only	Alpha only	Alphanumeric only

_{*Format must be consistent for the business object once selected. For example, a project that is initiated in NAV, i.e., the system of record for the project is NAV, the reference ID will be in the format Project-NAV-1234.

1 Use external object name if Workday is not the system of record, as it maps to the Workday object.

2 Accepted values only. Click here to access accepted application system acronym values. Reach out to Data Governance & Business Intelligence if the reference list does not include the system name and acronym needed for your reference ID.}

Note: Do not change the value of Reference IDs already in use as changing an active value can lead to some major downstream effects. One must consider the impact on these other systems before making changes.

Compliance

This standard must be complied with through every stage of the data lifecycle with the exception of any dispensations (see Dispensation section below):

All applications must define Reference IDs as recommended in this standard.
Enterprise Data Integration must adopt this standard.

Dispensation

Any reference IDs associated with Foundational Data Elements that have already been created in Workday may remain as-is.