All Collections
Best Practice Guides
Best Practices around Groups Object
Best Practices around Groups Object

Overview of Groups Object and how to leverage show_enum_origins

Yash Gogri avatar
Written by Yash Gogri
Updated over a week ago

Overview of Groups Object

The Group object is used to represent any subset of employees, such as Department, Paygroup, Division, Team, or any additional type of company hiearchy.

  • If your customer has multiple types of groupings (for example Division, Cost Center, and Department) then all those groups will be created and you will be able to distinguish each by the type field

  • If an employee is in multiple Groups (fore example Finance Department in the West Coast Division), then Merge will create an ID for both of those Groups

How to leverage show_enum_origins for specific Integrations

There are some providers that are very configurable, where there’s no true way to normalize what Cost Center / Group maps to a specific Department, Team, Cost Center, etc. For example, one customer may use Cost Center 1 to map to Departments, and another customer may use Cost Center 3.

This occurs for UKG Pro, UKG Ready, Paylocity, and Proliant.

How to find the correct Group to surface in your product:

  1. When pulling from out GET/Groups endpoint, you will apply the show_enum_origins parameter on “type”

  2. During the onboarding process, build a way to ask the end-user what Cost Center they’d like to be leveraged for Team / Department / Cost Center, etc.

  3. Once you gather this information, you will only surface Groups with a type that matches the customer input

    • For UKG Ready → It’s done by Index 0, 1, 2, 3, 4, 5, 6, 7, 8

    • For UKG Pro → It’s done by Type and/or Org Level

    • For Paylocity → It’s done by Cost Center 1, 2, 3, 4, 5

If you have any questions, please reach out to us at [email protected]!

Did this answer your question?