Workday® Naming Conventions
While Workday does not set any hard and fast rules about naming conventions, most of us have come across situations where object naming has made a Workday project unnecessarily difficult. Many organizations can struggle with migration and duplication issues when they do not create and enforce naming conventions. In this blog post, we will share a few simple rules that Makse Group uses to save hours of frustration, lower costs, and reduce unnecessary redundancy.
1. Placeholder References
You define and name many objects in Workday, including reports, business processes, integrations, encryption keys, calculated fields, and templates. By following these general placeholder references when naming all Workday objects, you will be able to easily find and reuse existing objects rather than recreating them.
[Vendor name] - The vendor identifier code distinguishes one vendor from another and quickly identifies which items belong to which integration and/or vendor. Example: Aetna, ADP, ING, BoA
[Integration#] - The assigned integration number, as populated by the client or lead. Example: INT017, INT001
[Functional Area] - A 2-4 letter code to note the functional area or user group that the artifact applies to. Ex: HCM, FIN, PAY
[Short description] - A short description of the artifcat’s purpose. This should include the direction of the item and data or feed type. Example: Demographics Outbound, Payments Inbound, Comp Changes, Org Changes, Aging Invoices
Separator - Separate fields with a single underscore “_” this ensures all XML and reference IDs are generated without errors and prevents additional characters from appearing. This keeps text clean in the UI and prevents unnecessary character conversion.
2. Custom Reports
Custom reports can be created for both Functional and Integration users. Reports should never be shared between integrations and functional users but copied instead. To differentiate, we recommend the below convention prefixed with “CR” for Custom Report:
Integration Reports:
CR_[Integration#]_[Vendor name]_[Short Description]_[Direction]
Functional Reports:
CR_[Functional Area]_[Short Description]
Examples:
CR_INT044_ADP_Dependent_Info_Outbound
CR_PAY_Post_Term_Payments
CR_SHR_Alternate_IDs
The table below provides reference for some functional areas. Note that If a report is used across multiple areas, “SHR” should be used to note it is “Shared.”
3. Integration Systems
Integrations are primarily broken into delivered and custom integrations. Delivered integrations use templates that are created and maintained by Workday, including the API library, while custom integration (EIBs, RAAS, and Workday Studio) are custom built integrations. All should use the following format, but since Workday adds and updates template names often the “type” field is optional.
[Integration #]_[Type]_[Vendor name]_[Short Description]_[Direction]
Example: INT002_EIB_Aetna_Dental_Outbound, INT012_ADP_STU_Journals_Inbound, INT103_CCW_New_Hires_Outbound
The table below notes the different integration types and values but is not exhaustive and new templates may be introduced by Workday.
4. Calculated Fields
Calculated fields are widely used across the system and can be extremely useful, but they often duplicate delivered fields. It is very important to consider report specific vs. system wide calc fields. Report specific calc fields are exclusive to a single report, cannot be copied, and are not searchable. They have also had past issues with OX & Migration, so you should always test before creating a high number of report specific fields.
Any calc field that is commonly used in many reports or functional areas should be labeled with “SHR” to indicate it’s used in multiple areas. You should never edit an existing SHR calc field without approval. The format and field types are listed below.
CF_[Integration#/Functional Area]_[Type]_[short description]
Example: CF_INT201_ESI_National_ID, CF_SHR_Eval_Worker_Status
5. XSLTs & Transformations
XSLT and Document Transforms should use the following naming format:
[Type]_[Integration #]_[Integration type]_[short description]
Examples: XSLT_INT001_EIB_Demographic_Outbound, DT_INT003_CCW_ActiveDirectory_Outbound
6. Sequence or ID generators
It is extremely important to both name and update reference IDs for Sequence Generators correctly. Leaving the default generated reference ID can cause filenames and other generators to be overwritten during migration. Note that when editing the reference ID, you MUST include the underscore character ( _ ) to replace spaces.
SEQ_[Integration #]_[Integration type]_[vendor]_[short description]
Example: SEQ_INT034_EIB_ADP_Actuals_Outbound_Filename
Ref ID: SEQ_INT034_Actuals_Outbound_Filename
7. Integration System Users (ISUs) and Security Groups (ISSGs)
ISUs are created for every custom integration, vendors who are using web services, and as process owners. Since multiple ISUs could reference the same security group and we want to limit security to what is necessary, both the ISU and ISSG format should follow each other.
ISU_[Integration#/Functional Area]_[short description]
ISSG_[Integration#/Functional Area]_[short description]
Examples: ISU_INT034_ADP_Outbound, ISSG_INT034_ADP_Outbound
8. Special Tags
There are several situations where you might create temporary artifacts or have unneeded items in the tenant. To help streamline support and maintain good data hygiene in tenants, here are other tags that will be helpful.
Do Not Use - When something is no longer needed, outdated, deprecated, or intended to be removed you should mark the item as “Do Not Use” and ensure they return at the bottom of any search lists by adding the following prefix to any above artifact: zDNU. Example: zDNU_CR_INT044_ADP_Dependent_Info_Outbound
Personal or Proof of Concept - Anything that is not intended to be used in production can simply use the creator’s initials to replace any integration or vendor IDs. Example: JR_Test_LRV_Manager_Email, AM_Find_Worker, CR_AJ_Hour_Test
Summary
Naming conventions and governance should be a part of your implementation plan from the start. However, it is never too late to get on the right track. Not only will you lower frustration among your Workday users, but you also save time and money in rework and duplication. However, if you do not have the time and resources to update your Workday naming conventions and governance, you can always take advantage of Makse Group’s Assess & Recommend services to optimize your business processes and applications for success. Contact us now and talk to a Workday expert today!
