Best Practices for Object Names in Workday®

In our careers in human capital management systems, most of us have come across situations where lax discipline in object names made the work harder. In one ERP implementation, an organization started with good intentions but didn’t follow up. They published well-structured rules for naming reports, business processes, integrations, and queries. They placed them in the training materials on their intranet and mentioned the rules in training.

Then they forgot about them.

Seven years later, the HR Director asked us to figure out how to get a meaningful reports from years of transactional data. The first assignment was to design a report that would tell him how many employees were in each employee group. That task took three weeks.

That’s an extreme case, but many organizations struggle when they do not create and enforce naming conventions. With a structured approach to governance and a few simple rules, you can save hours of frustration, lower your costs, and reduce unnecessary duplication.

Workday® Design Difference

One thing you notice first when you use Workday® is that its object names are plain language, not codes. You may need to learn word meanings, but you do not need a translation table. Learning is faster, and returning to operations you have not done for a while is much easier than when you had to relearn codes. When you set up Workday®, you can carry this concept into the objects you name.

Best Practices

You define and name many objects in Workday®. These include reports, business processes, integrations, encryption keys, calculated fields, and templates. You will gain much by following a set of naming rules. One of the primary benefits of consistent names is that you can find and reuse existing objects rather than re-create them.

A few best practices will help you avoid problems when you name your objects.

Recommendations for All Objects

• Use plain language. A new user should be able to see an object in context and understand the name. If you use multiple languages, have a native speaker in each language review the object name in context.
• Use abbreviations only if they are common acronyms or readily understandable in context. For example, “RCF_” could be a good prefix for calculated fields in report design. “ICF_” would then work for intermediate calculated fields.
• Do not abbreviate business object names. Object names can be similar and abbreviations can obscure the meaning. For example, if you use a business object name in a report name, use the entire business object name.
• For country and region codes, you can use ISO standards. ISO maintains both 2-letter and 3-letter codes. If your organization uses geographic or other organizational codes, use them only if users will recognize them.
• Use function names: Budget, Benefits, Payroll, Procurement, etc.
• Where an object name allows spaces, use title case. If the object requires contiguous characters (no spaces), use camel case. (ThisIsCamelCase.)

Report Names

• Use title case. Title or proper case is easier to read. Strings of capital letters are difficult.
• Be specific. Avoid general terms such as “Benefits Report.” Use a specific name such as “Employee Pre-Tax Benefits Deductions.”
• Show temporary reports with a suffix. If a report will not be evergreen, add the word “Temporary” to the end of the name, and delete the report when you no longer need it.
• Do not use ampersands. Do not use the “&” character. Use “and” instead. In HTML pages and XML operations, the ampersand character tells the browser to display a special character.
• Avoid hyphens. Use them only if they what a user would type in a search. If you need to use them as a separator, put a space before and after the hyphen.

Integrations

• Identify the Workday® platform used to create the integration: connector name, toolkit name, EIB, or Studio.
• Name the integration direction from the Workday® perspective: Inbound and Outbound.
• Where a consultant or integrator create objects, show the integrating partner in the name to help if you need rework later.
• Identify the target application, location, and business unit, if applicable.
• In encryption key names, use the issuer, direction, key type, and target.

Transformations and Mapping

• In transformations and mapping include transformation type (XSLT), integration name, and layout type (fixed, CSV, pipe-delimited)
• In mapping templates, include the operation type (GET), field name, transfer type, and variables used to generate fields.

Governance

We recommend a governance process that will help compliance. You can do this with automated reports.

• Include object naming in your training for every person who has permission to name them. Don’t forget transfers and promotions.
• Reinforce training with frequent communication.
• Create custom reports that show objects that do not follow the rules.
• Run reports often enough that follow-up is not a burden.

Summary

Naming conventions and governance should be a part of your implementation plan. 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 your time and money in rework and duplication.

Pixentia is a full-service technology company dedicated to helping clients solve business problems, improve the capability of their people, and achieve better results.