Introduction

We have two options to feed data that is not already in Employee Central into Compensation columns :

• Compensation module Lookup tables (if Country = X and City = Y, then assign value Z in the column for each employee that matches this combination of attributes).
• MDF Objects (by UserID only, cannot use an if-then logic like Lookup tables unless business rules are added to the MDF onSave).

Why would we chose one or the other ?

Whenever possible we want to avoid using BOTH because then Compensation administrators will need to make updates in 2 different places with 2 different import files before launching compensation worksheets.

Why would we have a situation with both ?

• If the customer’s Comp Administrator receives data from other internal streams (Finance, Payroll,…) for some columns (for example Budget %) as a table that looks like our Compensation Lookup tables (in which case it saves time to Comp Admin to upload it as-is into compensation module Lookup tables).
• BUT let’s say there are also some columns that require a unique value for each user and most users in the compensation cycle are going to need that data (we’re talking thousands of employees, please see next paragraphs below in case that data is just for a few hundreds). Then we don’t want to create a Lookup table by USERID because it is likely to create latency issues when using the Compensation module (see this article here).

So when should we go ONLY with Lookup Tables ?

• If the customer gets most data as Tables and the few columns with values varying by USERID are only for a few hundred employees (only Executives for example), then only using Lookup Tables is acceptable. We should however make sure to check the following setting in Actions For All Plans > Company Settings : “Encrypt lookup table data”.

When should we consider using ONLY MDF ?

• If the customer gets data from an external system (Finance, Payroll…) already by USERID then it doesn’t make sense to ask them to transform the data into Lookup tables and we might as well create one MDF object with a row for each data and have the customer load data for each employee in it.

Known limitations :

• The above applies to Compensation templates primarily but also valid for Variable Pay entry level columns which support MDF integration. Please be aware that as of 1H 2022 the Variable Pay Employee history (varpayemphist background elements) and Assignment Level Custom Fields (ALCF) cannot be mapped to MDF objects.

A walkthrough recording with a demo will be inserted here in the next days.

All the best,

Xavier