Organization data includes Participants, Titles, Positions, and Relationships. This is where the system stores information about the entities who are being compensated: the individuals who receive payments, the unique jobs that they do, and the titles they share.
While organization data can be created manually in the user interface, this data is more often imported from source systems in a production environment. As an organization changes over time, it will be necessary to create and modify organization data. These changes may include adding or removing participants, creating new positions, or changing the reporting structure when people transfer within departments, receive promotions, or leave the company.
Organization Data
Participants
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 wautomatically 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.
Best Practices for Participants
- 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.
- End dating Participants is not recommended. If a participant leaves the organization, remove them from their assigned position, but leave their record active in the system. This makes it easier to find their record if needed.
- 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. This is because once the termination date is past, the user is automatically locked out of the system.
Positions
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.
Position Groups
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.
Custom Processing Dates
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. Melissa is leaving the position, and Mona is replacing her. Melissa 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:

Melissa is assigned to SR-South with the following effective dates:
- SR-South version 1 is effective January 1, 2020 to February 28, 2022.
- Melissa is receiving credits and processing effective January 1, 2020 to March 15, 2022
Mona is assigned to SR-South with the following effective dates:
- SR-South version 2 is effective March 1, 2022 to End Of Time.
- Version 2 is receiving credits and processing effective March 16, 2022 to End Of Time.
In the March 2022 period, both Melissa and Mona receive credits based on transactions with compensation dates between March 1 and March 15. For transactions that have compensation dates after March 16, only Mona 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.
Best Practices for Positions
- 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 is 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 would change frequently.
Titles
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.