Calculated Field Design Etiquette (⚠️Don’t Build Otherwise)
One of the most powerful ways to take ownership of your Workday data is through the use of Calculated Fields. As long as the data is in Workday, you can (usually) get to the exact piece of information you’re looking for within your own parameters. BUT! There’s a catch – a steep learning curve. So! While you’re on the learning curve, let’s get some things straight so you 1) avoid creating bad habits, and 2) configure like an EVOCs consultant. Here are the major dos and don’ts of calculated field design etiquette starting with your choice tenant.
Where to build a calculated field?
There are two choices when deciding where to begin building a calculated field. The first is which tenant. The second is whether the calculated field should be accessed tenant-wide or be report-specific. Here’s the best practice.
Create first drafts in testing tenants
There are false starts when creating calculated fields. You think something will work, but, to your dismay, the output pulls an unintended value or straight-up blank. It takes time to figure out. Because of this, DO NOT BUILD UNPROVEN CALCULATED FIELDS STRAIGHT IN PROD. Unless you remember all the no-go fields you created (unlikely), you’re going to unintentionally clog up your tenant and cause confusion for the report writers who come after you. We’ve all seen the calculated fields like “AJ TEST Termination” floating around, and chances are Mr. Al Johnson doesn’t work here anymore.
So, instead of PROD, use the Preview or Sandbox tenants. When your calculated field has proven itself, migrate to PROD and let your scribbles be erased by the next refresh. WHEW!
Build report-specific calculated fields when they need to be protected
There’s a risk every calculated field experiences, and it’s that someone else with report writer access could edit and break it. (You probably have someone in mind who either did this to you or knows just enough to be dangerous.) One of the ways to protect your calculated field is to make it report-specific. This means the calculated field can’t be used in other reports or functions across the tenant. The likelihood of it getting messed with decreases astronomically. This is especially useful for RaaS reports where the information within gets sent on a regular basis via integration to another source. That’s one place you definitely don’t want the fields breaking, so report-specific fields add peace of mind.
TLDR
Do: Use Preview or SBX tenants to build calculated fields for tenant hygiene, and use report-specific calculated fields for RaaS reports.
Don’t: Build straight in PROD
How to name a calculated field?
Remember “AJ TEST Termination”? Not only does it look like a mistake in the tenant, but it also doesn’t tell me nearly enough information about its output. Will it show the termination event, the date, or the reason? Does it include future-dated terminations? Will it show me the past termination of rehires who are currently active? You need to think of naming your calculated field as an opportunity for collaboration with the report writers who come after you. Here is the etiquette.
Use a prefix, e.g. CF TF - [Name]
The prefix has a number of uses. “CF”, which stands for “calculated field”. It’s your at-a-glance signal to all future report writers that this field is created, not delivered.
Next, include an acronym to indicate the type of calculated field you’re making. A True/False field is typically abbreviated as “TF”. A lookup-related value field is LRV. With practice it becomes intuitive. You’re telling other report writers details about the field type or method. You’re ALSO telling them you’re a super cool Workday configurator who knows the etiquette…😏
BONUS: You can type in LRV or ESI etc as a shortcut for selecting the field type upon creation.
Name the calculated field exactly what the logic says
There’s no lying to you. Sometimes the title gets LONNGG because the logic can be layered and complex. Don’t fret. The report’s column heading override solves this problem, allowing you to display whatever title makes sense to your end-user running the report. But for your fellow report writers? Name the calculated field properly so they have the insight at first glance.
For example, if you build a calculated field that pulls the most recent termination event’s effective date that includes future events, you should name it exactly that –
CF LRV – Most Recent Termination Event (incl Future-Dated) Effective Date
With a clear enough name, you’ll save other report writers from time spent investigating what the freak your field does. They’ll know right away whether the one you created serves their purpose.
Overall, a good naming convention will –
- Reduce duplicate efforts
- Lead to better use of your calculated field throughout the tenant
- Give the hint to STAY AWAY from using or editing something unrelated to their work.
TLDR
Do’s: Name your calculated field exactly what the logic pulls and include a prefix for CF [Field Type Acronym] –
Don’ts: Name your calculated field something unclear or misleading, including your initials (embarrassing).
Common Mistakes
And lastly, common mistakes. The tea you’ve all been waiting for. What are the hints someone is an inexperienced calculated field creator?
Unnecessary Layers
Let’s say you want to create an evaluated expression field to return a certain value if a Worker is On Leave. There’s a WD-delivered True/False field (also called boolean) specifically for On Leave. This can be placed directly into the calculated field condition slot. There’s no need to create another True/False calculated field for On Leave = CHECK. If you did, you’d be creating an unnecessary layer of logic.
Taking the Scenic Route
The only time this will ever be said. But, when making a calculated field opt not to take the scenic route. There are many ways you can make a calculated field, and you should spend time with the logic to narrow it down to the path of least resistance. Your calculated field will much run faster in reports, and appear clean and clear to those who find it after you.
Not Copying Calculated Fields
There are times you create a calculated field for a number of similar instances. Rather than recreate each from scratch, copy the existing calculated field you’ve proven and swap out the value that changes the output. This is common for Payroll calculated fields where you can swap out a T/F that designates a particular earning code, and for reporting on questionnaire responses where you swap out the question of interest. Copying a calculated field is a much faster way to create the “set” for your purposes, and it keeps your nomenclature more consistent.
The other case for copying a calculated field is that you may be able to use an existing one as a springboard! You don’t want to edit someone else’s work (unless it was made years ago and isn’t being used anywhere), but copying is fair game. Use the resources available to you! And if another calculated field looks on track for your purposes, give yourself the headstart.
TLDR
Do’s: Configure the shortest possible route of logic and copy calculated fields for a lighter workload.
Don’ts: Create long-winded calculated fields, each from scratch.
Conclusion
Learning to create calculated fields transforms how you leverage data in your tenant. Learning how to create them with etiquette provides your organization with those insights without compromising tenant health. It also makes you stand out from the crowd as an HRIS Analyst or Consultant who understands the larger impact of each configuration decision. Remember, your work is your brand. And you want future report writers to associate you with great work. Godspeed!