Skip to Content
Technical Articles
Author's profile photo Xavier Le Garrec

How to filter on several Line Manager or HR Manager names in Compensation Executive Review


It may seem like something easy to do but depending on the configuration of an environment it can be difficult to build a filter in Compensation Executive review that allows us to filter on several manager names (not ID) that are not connected through a reporting line, for the following reasons :

  • The Executive Review doesn’t offer anything in standard to do this : we can only filter on one manager name or HR manager name at the time and then decide which levels below them in the reporting line we want to show.
  • Username columns that show the name of a manager on the worksheet when mapped to EC Category = Job Info > Supervisor or EC Category = Job Info > HR manager job relationship are not yet supported in Executive Review and will not show in filter selection.
  • We can try mapping a custom column of type “string” to EC Category = Employee Profile > Manager and another column to EC Category = Employee Profile > HR manager but we found after testing that it doesn’t return the name of the manager in all environments (sometimes it returns the ID and we are still trying to troubleshoot what is causing this). We recommend trying this solution (which is by far the easiest – when it’s working) and if it returns the ID of the manager and not the name then please follow guidance below.


Solution that always works

In this 20 minutes recording we show how to build a custom MDF object that allows planners and administrators to filter in Compensation Executive Review on several Line Managers or HR Managers (and by using their name vs userID) that are not in the same reporting line, which is not possible yet using standard tools.

The recording covers the following steps :

  1. The creation of a custom MDF object (with externalCode=User so it can be used in Compensation) that will store the managers’ names.
  2. The creation of a business rule that populates the managers’ names on save.
  3. The creation of an integration center job that automatically captures changes on a daily basis thanks to a scheduled job.
  4. How to link the MDF values to compensation template columns.
  5. How to filter once the workaround is in place.




Not only does this solution always work but it also allows us to create deep job relationship filters, for example if we want to see on the worksheet who is a person’s “Level 3 manager” or “Level 4 manager” we can do so by creating the appropriate new field in the custom MDF object and then by nesting the mapping in the On Save business rule of the MDF object (Example for level 3 : Job Info > Supervisor > Job Info > Supervisor > Job Info >



All the best





(If you found this blog useful please consider giving it a Like)


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo mridul sharma
      mridul sharma

      thanks a lot Xavier Le Garrec  for sharing this

      Author's profile photo Nicolas Chilles
      Nicolas Chilles

      Hi Xavier Le Garrec , I am trying to implement this and within the Integration Center, all the records fail because it says:
      UPSERT failed for the row with key: . Reason: Please add required properties in payload. Required property effectiveStartDate is missing. You can check which properties are required for an entity in Admin Center > OData API Data Dictionary or the entity metadata.

      Did I miss anything? Because from your recording, I don't see that you're initiatlizing the jobRelationshipsNames.effectiveDate with anything, or?

      But I understand why it would be failing if indeed we don't pass anything into it since it's a primary key. Right?

      Author's profile photo Nicolas Chilles
      Nicolas Chilles

      I did the test of linking the Job Information.Start Date with the Job Relationships Names.Effective Date and it did work now. But here, ideally, if we wanted to be squared, we would only synchronize the Job Relationships Portlet (standard) with our custom one and therefore use as a starting point the Job Relationships standard portlet and use its effective date, right?

      Because in our case, having Line Manager is nice and its effective date is the one of the Job Information portlet indeed, but for other relationships, it's the effective date of the Job Relationships portlet that matters.

      Author's profile photo Xavier Le Garrec
      Xavier Le Garrec
      Blog Post Author

      Hi Nicolas Chilles

      What is the business case where Job Info effective date is different from Job Relationship effective date ? In my demo I use top of stack indeed (job relationship effective date).

      All the best


      Author's profile photo Nicolas Chilles
      Nicolas Chilles

      Hi Xavier Le Garrec ,

      The customer needs to replace the Compensation Planner of one employee because he or she (the compensation planner) has been transferred temporarily onto a temporary mission during which he or she will not be able to fulfill his/her responsibility of compensation planning.

      Therefore, they are NOT editing the Job Information of the employee because nothing is changing for him/her, but they are changing the Job Relationships portlet to notify that the Compensation Planner is indeed changing as of the compensation planner's temporary mission start date.