Managing Organization Data

A Participant is the entity that is compensated in a plan. While generally a participant is an individual, it can also be a team or group. Participants can be internal or external to the organization.

A Participant record can also represent other stakeholders, such as approvers who need to be included in a process workflow, and others who need access to dashboards or reports.

The Participant record contains all information that pertains to the Participant, such as the name, base salary, and hire date. The Last Name and Participant ID fields are required fields.

General Information for Participants includes the following:

• First and Last Name
• Payee ID
• User Name
• Base Salary
• Hire and Termination Dates

Every Participant has a User Name. If the participant record is saved or loaded without populating the User Name field, the record automatically populates the User Name with the Participant ID. If the organization is using Single Sign-On, the User Name should be the same as the user’s system login.

Use Generic Attributes to store additional Participant information as needed.

• Determine the Username/User ID format before adding participants to the system.
• Do not use a Username/User ID that may change.
• With Single Sign-On, use the User ID used by the company’s current systems.
• Use a generic date to represent the end of the participant’s employment and use this date in rule logic instead of the Termination Date field. This is because once the value in the Termination Date field is past, the user is automatically locked out of the system.

The Position contains information about the unique job that is being compensated. Compensation is calculated in the context of the Position, not the Participant. As a result, the Position record is more important than the Participant or the Title, although all three are required.

A few points regarding positions are:

• Positions define specific jobs that participants perform within a company.
• One participant can be assigned to multiple positions.
• One position can have only one participant assigned.
• If no participant is assigned to a position, the position won't receive compensation.
• Each position is grouped under a Title.

The Position Group field on the position record is not required. However, it is a useful feature that is used in most implementations. Use this field to group together positions by a value other than the title. This is useful for filtering data in compensation rules, and for running pipelines for subsets of positions. For example, you may want to have different position groups to differentiate sales teams, or teams in different corporate offices.

This field is a dropdown list that is populated as a Global Value.

The Position record has four fields that are used to fine-tune the start and end dates for Position Assignments: Credit Start, Credit End, Processing Start,and Processing End. Use these fields in cases where the dates that a participant is compensated does not correspond to the dates in which they hold the position.

Let’s look at an example of a Position called SR-South. Amy is leaving the position, and Stacy is replacing her. Amy should receive credits and payments for fifteen days after she leaves the position, during which time both participants should receive credits and payments. To make this work, the following would be configured:

Amy is assigned to the Sales Rep Southwest position with the following effective dates:

• Sales Rep Southwest version 1 is effective January 1, 2025 to Febuary 28, 2025.
• Amy is receiving credits and processing effective January 1, 2025 to March 15, 2025

Stacy is assigned to the Sales Rep Southwest position with the following effective dates:

• Sales Rep Southwest version 2 is effective March 1, 2025 to End Of Time
• Version 2 is receiving credits and processing effective March 16, 2025 to End Of Time

In the March 2025 period, both Amy and Stacy receive credits based on transactions with compensation dates between March 1 and March 15. For transactions that have compensation dates after March 16, only Stacy receives credits.

It would appear this would create an overlap in the first half of March, but the custom credit and processing dates prevent this by specifying the exact dates in which each participant is compensated.

• Avoid changing position names over time. The position name is the unique key identifier for a Position. If the position name changes, errors can occur when loading variable assignments and quotas, and running the calculation.
• Custom Credit/Processing dates should only be used for exceptions. If these need to be modified regularly, automated loads that are programed to set the dates appropriately are highly recommended. Otherwise, position maintenance can become overwhelming.
• Don’t assign Positions directly to a plan. Instead, assign the title to a plan and allow the position to inherit the plan assignment.
• Set up position groups for your positions from the start, so that if you ever need to, you can post and finalize by a position group. Position groups should not be groupings that might change frequently.

Titles are used to group similar positions across the organization and usually group positions related to job functions.

As an example, Sales Representatives in an organization might share the same title, but each sales representative may hold a unique position, such as Sales Rep Northwest or Sales Rep Hardware Products.

Generally, all payees who are compensated in similar ways can share a compensation plan, so compensation plans are assigned on the Title level rather than on the Position level.

The Detail pane of the Titles workspace contains two core tabs: General Information and Assignments. If generic attributes have been enabled for Titles, a custom fields section is also displayed in the Titles detail pane.

The General Information tab contains the Title Name, Business Unit, Plan, and Description.