Have you ever…

Built the perfect calculated field only to discover it’s not selectable in a Payroll calculation?

Needed to reference a worker schedule, custom object, or some other worker attribute in an Accrual calculation, only to hit a dead end?

You KNOW the data exists, so why can’t you use it?

The Calculation Engine, used to build Payroll and Absence calculations, has its own set of calculation types and available inputs — they don’t always play nicely with the worker data you can access through calculated fields.

But there’s a proven method for bridging that gap 🤓 And once you understand it, you can build more dynamic eligibility rules, calculations, and other logic without resorting to workarounds.

Let’s get into it.

So, why can you build a perfectly good calculated field and then hit a wall when you try to use that same data in the Calculation Engine?

Calculated fields work directly with a business object. In fact, that’s one of the first required inputs! After making that selection, you get access to that business object’s fields, then — based on your chosen calc field type — you can retrieve, evaluate, and/or transform the field’s data.

The Calculation Engine is, ummm, not so straightforward. The data it has access to is more narrow and isn’t as clearly defined.

When you try to bring certain worker data into a Payroll or Absence calculation, you typically hit one of two roadblocks 🚧:

So to get the worker data and the Calculation Engine to connect, you need to build a detour around these roadblocks!

Here’s how that typically looks: