Plan Administration & Participant Management in Callidus Commissions

Understanding Compensation Plans

A compensation plan in Callidus Commissions is the definition of how incentives are calculated. It specifies the rules, the periods, the plan type, and the business logic. A company might have multiple compensation plans running in parallel: one for direct sales, one for channel partners, one for customer success managers, one for sales engineers.

The plan definition itself lives in the CS_COMP_PLAN table. Core fields include:

• ID — unique plan identifier (often a numeric ID, e.g., 1001, 1002)
• NAME — human-readable name (e.g., "EMEA Sales Commission 2026")
• PLAN_TYPE — category: Commission, Bonus, SPIF (Special Incentive Fund), Adjustment
• STATUS — Active, Inactive, Draft, Archived
• EFFECTIVE_START — when the plan becomes active
• EFFECTIVE_END — when the plan expires (can be NULL for open-ended plans)
• DESCRIPTION — notes about the plan
• CREATED_DATE, LAST_MODIFIED_DATE — audit fields

The plan itself doesn't contain the calculation rules (those are in CS_PLAN_RULE, which we'll discuss in a later lesson). The CS_COMP_PLAN table is just the header — it identifies the plan and its lifecycle.

Plan Periods

A plan runs across multiple periods. In a sales organization, periods are usually monthly or quarterly. Each period is a distinct calculation run. A participant's compensation for January 2026 is calculated separately from February 2026, even though they're on the same plan.

Periods are stored in CS_PLAN_PERIOD:

• ID — unique period identifier
• PLAN_ID — foreign key to CS_COMP_PLAN
• PERIOD_NAME — e.g., "January 2026", "Q1 2026"
• PERIOD_TYPE — Monthly, Quarterly, Annual, Custom
• START_DATE — when the period begins (e.g., 2026-01-01)
• END_DATE — when the period ends (e.g., 2026-01-31)
• STATUS — Open, Locked, Calculated, Final

The period status tells you the lifecycle: Open (accepting new transactions), Locked (transactions frozen, calculation running), Calculated (calculation complete, being validated), Final (complete and approved). Once a period is Final, you cannot change transactions in it — all changes are handled as adjustments in a future period.

What Is a Participant?

A participant is any person who can earn compensation in a Callidus system. That's not just sales reps. It includes:

• Sales Representatives — direct individual contributors who sell
• Sales Managers — who oversee reps and may have their own quota/override compensation
• Directors and VPs — senior sales leadership
• Channel Partners / Resellers — external partners who sell on behalf of the company
• Sales Engineers — may have a commission component for large deals
• Customer Success Managers — may have retention bonuses
• Non-sales roles — marketing, support, finance teams that have incentive components

The key insight is: a participant is anyone who can earn, not a job title. A person holding the same job title might participate in multiple plans (base commission + SPIF). A person might not participate in any incentive plan (support staff).

Participants are stored in CS_PARTICIPANT:

• ID — unique participant ID (often matches HR system employee ID)
• NAME — full name
• EMPLOYEE_ID — link to HR system (e.g., Workday or SAP HCM ID)
• EMAIL — contact email
• POSITION_ID — references CS_POSITION (role classification)
• PARENT_ID — manager's participant ID (for hierarchy building)
• STATUS — Active, Inactive, On_Leave, Separated
• EFFECTIVE_DATE — when the participant record became active
• TERMINATION_DATE — if separated, when
• CREATED_DATE, LAST_MODIFIED_DATE — audit fields

Building Organizational Hierarchies

The PARENT_ID field creates a tree structure. You can query the hierarchy using hierarchical SQL or recursive CTEs. Here's a practical example:

-- Find all direct reports under a manager
SELECT p.id, p.name, p.position_id
FROM   cs_participant p
WHERE  p.parent_id = 12345  -- manager's participant ID
AND    p.status = 'Active'
ORDER BY p.name;

-- Find the chain of command (rep -> manager -> director)
WITH hierarchy AS (
  SELECT id, name, parent_id, 1 AS level_num
  FROM   cs_participant
  WHERE  id = 99999  -- start with a specific rep
  UNION ALL
  SELECT p.id, p.name, p.parent_id,
         h.level_num + 1
  FROM   cs_participant p
  INNER JOIN hierarchy h ON p.id = h.parent_id
)
SELECT * FROM hierarchy
ORDER BY level_num;

That second query is powerful: it traces a rep all the way up to the top of the organization. You can use it to build reporting hierarchies, calculate override bonuses (manager gets a percentage of all direct reports' compensation), or audit the org structure.

Plan Assignments via CS_PLAN_PARTICIPANT

A participant doesn't automatically earn in every plan. You must explicitly assign them. That's what CS_PLAN_PARTICIPANT does — it's the bridge between participants and plans.

Key fields in CS_PLAN_PARTICIPANT:

• PLAN_ID — which plan (foreign key to CS_COMP_PLAN)
• PARTICIPANT_ID — which participant (foreign key to CS_PARTICIPANT)
• PERIOD_ID — which period (foreign key to CS_PLAN_PERIOD)
• QUOTA_AMOUNT — the quota for this participant in this plan in this period
• EFFECTIVE_START — when the assignment becomes active
• EFFECTIVE_END — when the assignment expires
• STATUS — Active, Inactive, On_Hold

This design is flexible: the same participant can have different quotas in different periods (quota can change mid-year). The same participant can be assigned to multiple plans. A plan can have hundreds of participants with individual quotas.

-- Find all participants in a specific plan and period
SELECT cp.participant_id, p.name, p.position_id,
       pp.quota_amount, pp.status
FROM   cs_plan_participant pp
INNER JOIN cs_participant p ON pp.participant_id = p.id
INNER JOIN cs_comp_plan cp ON pp.plan_id = cp.id
WHERE  cp.id = 1001  -- plan ID
AND    pp.period_id = 5001  -- period ID
AND    pp.status = 'Active'
ORDER BY p.name;

-- List all plans a participant is assigned to
SELECT cp.id, cp.name, cp.plan_type,
       pp.quota_amount, pp.period_id
FROM   cs_plan_participant pp
INNER JOIN cs_comp_plan cp ON pp.plan_id = cp.id
WHERE  pp.participant_id = 99999  -- participant ID
ORDER BY cp.name, pp.period_id;

Quota Management via CS_QUOTA

Quota is central to commission calculation. A participant's commission is usually based on a percentage of attainment (% of quota achieved). Quotas are managed in the CS_QUOTA table, though the primary quota for a period is typically stored in CS_PLAN_PARTICIPANT.QUOTA_AMOUNT.

The CS_QUOTA table is used for:

• Quota history — tracking quota changes over time (audit trail)
• Segment quotas — if a rep has multiple territories or segments, each might have its own quota
• Target quotas — vs. actual booked quota
• Quota splits — for deal teams, how is quota shared across participants

-- Get quota for a specific participant and period
SELECT pp.quota_amount
FROM   cs_plan_participant pp
WHERE  pp.participant_id = 99999
AND    pp.period_id = 5001
AND    pp.plan_id = 1001;

-- Find participants with zero quota (edge case)
SELECT p.id, p.name, pp.quota_amount
FROM   cs_plan_participant pp
INNER JOIN cs_participant p ON pp.participant_id = p.id
WHERE  pp.plan_id = 1001
AND    pp.period_id = 5001
AND    (pp.quota_amount IS NULL OR pp.quota_amount = 0);

Position Types and Roles

The CS_POSITION table classifies participant roles. Standard position types include:

• Sales_Rep — direct individual contributor in sales
• Sales_Manager — first-line manager
• Sales_Director — regional or functional director
• VP_Sales — executive
• Channel_Partner — external partner
• Solutions_Engineer — technical role with commission component
• Customer_Success — retention or expansion role

Position types are often used to apply different rules to different participant categories. For example, a Sales_Rep's compensation might be pure commission, while a Sales_Manager's compensation might be commission + override (a percentage of their team's earnings). The calculation engine checks the position type and applies the appropriate rule.

Active vs. Inactive Status

Participants have a STATUS field that controls whether they're included in compensation calculations. Common statuses:

• Active — eligible for compensation in current and future periods
• Inactive — not eligible (can be archived)
• On_Leave — temporarily inactive (maternity, sabbatical)
• Separated — left the company (final compensation paid in their last period)

The EFFECTIVE_DATE and TERMINATION_DATE fields mark when status changes apply. If a participant is hired mid-period, their EFFECTIVE_DATE is the hire date. If they're terminated, TERMINATION_DATE marks their last day, and status changes to Separated.

-- Find all active participants assigned to a plan
-- with non-zero quota in a specific period
SELECT p.id, p.name, p.position_id,
       pp.quota_amount, p.status
FROM   cs_plan_participant pp
INNER JOIN cs_participant p ON pp.participant_id = p.id
INNER JOIN cs_position pos ON p.position_id = pos.id
WHERE  pp.plan_id = 1001
AND    pp.period_id = 5001
AND    p.status = 'Active'
AND    pp.status = 'Active'
AND    pp.quota_amount > 0
AND    pos.position_type = 'Sales_Rep'
ORDER BY p.name;

Common Data Quality Issues

When working with Participant and Plan data, watch for these issues:

• Orphan participants — a participant in CS_PARTICIPANT has no plan assignment (CS_PLAN_PARTICIPANT). They won't earn anything, which might be intentional (support staff) or a data quality issue.
• Circular hierarchy — a participant's PARENT_ID points to themselves or creates a loop. The hierarchy query will hang. Check for cycles with: SELECT p.id FROM cs_participant p WHERE p.parent_id = p.id
• Zero quota edge case — a participant is assigned to a plan but has zero or NULL quota. The calculation engine might divide by zero or treat this as "no calculation." Check the plan logic.
• Overlapping plan assignments — a participant is assigned to the same plan twice in overlapping periods. Which assignment wins? Usually the one with the latest EFFECTIVE_START, but verify with your implementation.
• Inactive participants in plan calculations — a participant's status is Inactive, but they're still assigned to an active plan. The pipeline might or might not process them; check your filter logic.