Participant Management: The People Layer

If Plan Administration is the strategy layer, Participant Management is the people layer of SAP SuccessFactors IM. A plan is just rules until you assign it to people. This lesson covers who participants are, how to structure and import them, how to manage hierarchies, and critically, how to avoid the orphaned participant trap that leaves people with zero pay.

What is a Participant?

A participant is anyone who needs a compensation plan. This is broader than you might think. In SAP SuccessFactors IM, the CSC_PARTICIPANT table stores:

• Direct sales reps — The obvious case. Commission-based sellers who have quotas and earn on results.
• Sales managers — May have their own quota (team revenue target) or a bonus tied to team attainment. Must be in CSC_PARTICIPANT to receive plans.
• Specialists and support roles — Customer success managers, solutions engineers, field engineers may earn commission on renewal or upsell revenue.
• Overlay reps — Sales people who work on the same deal but in a supporting capacity (e.g., technical overlay on a complex sale). Each gets their own line in CSC_PARTICIPANT and their own plan assignment.
• Channel partners and resellers — If managed in SAP SuccessFactors IM (rather than a partner portal), they need participant records.

The key insight: participant status is driven by whether someone is eligible to earn incentives, not their job title. If they touch a compensable metric, they need to be in CSC_PARTICIPANT.

The CSC_PARTICIPANT Table: Core Fields

Each participant record has these essential fields:

-- CSC_PARTICIPANT core fields
PARTICIPANT_ID        -- Unique identifier for this person (e.g., 'JSMITH001')
NAME                   -- Full name or display name
EMPLOYEE_ID           -- Link to HR system (SAP SuccessFactors HCM)
POSITION_ID           -- Position code (e.g., 'SALES_REP_WEST')
MANAGER_ID            -- PARTICIPANT_ID of the direct manager; creates the org tree
STATUS                 -- 'ACTIVE', 'INACTIVE', 'TERMINATED'
HIRE_DATE              -- Start date in the organization
TERMINATION_DATE      -- End date; NULL if still employed
DEPARTMENT_ID         -- Organizational unit (e.g., 'NA_SALES', 'EMEA_SALES')
COUNTRY_CODE          -- For geographic modifiers in plan calculations
CREATED_DATE          -- When record was imported or created
LAST_MODIFIED_DATE    -- Audit trail for updates

The most important field is MANAGER_ID. It creates the organizational hierarchy. If JSMITH001's MANAGER_ID points to JDOE001, then JDOE001 is JSMITH001's manager. This relationship is critical for:

• Building manager rollup views (showing a manager's total team incentive payouts)
• Routing approvals up the chain
• Determining territory overlap (if two reps report to the same manager, they may have a shared quota)

Participant Hierarchies and Recursive Queries

Your organization is a tree. The CEO reports to no one (MANAGER_ID = NULL). Each manager reports upward. To traverse this hierarchy on SAP HANA Database, use a recursive CTE:

-- Recursive CTE: walk from a leaf participant to the root (CEO)
WITH RECURSIVE ORG_PATH AS (
  -- Anchor: start with a specific participant (e.g., JSMITH001)
  SELECT
    PARTICIPANT_ID,
    NAME,
    MANAGER_ID,
    1                      AS LEVEL,
    NAME                    AS PATH
  FROM CSC_PARTICIPANT
  WHERE PARTICIPANT_ID = 'JSMITH001'

  UNION ALL

  -- Recursive: climb up to the manager, then their manager, etc.
  SELECT
    cp.PARTICIPANT_ID,
    cp.NAME,
    cp.MANAGER_ID,
    op.LEVEL + 1          AS LEVEL,
    CONCAT(cp.NAME, ' → ', op.PATH) AS PATH
  FROM ORG_PATH op
  JOIN CSC_PARTICIPANT cp
    ON cp.PARTICIPANT_ID = op.MANAGER_ID
  WHERE op.MANAGER_ID IS NOT NULL
)
SELECT PARTICIPANT_ID, NAME, MANAGER_ID, LEVEL, PATH
FROM ORG_PATH
ORDER BY LEVEL;

This query walks from JSMITH001 up the chain. If JSMITH001 → JDOE001 (manager) → JBROWN001 (director) → CEO, the PATH column shows: "JSMITH001 → JDOE001 → JBROWN001 → CEO". The LEVEL column counts steps. Useful for approval routing (route to manager at LEVEL 1) or for building manager rollups (sum results for all participants under a manager).

Position Types and Plan Eligibility

The POSITION_ID field determines what types of plans a participant is eligible for. Example position types:

• SALES_REP_WEST — Direct salesperson in Western region. Eligible for commission plans, bonus plans, SPF.
• FIELD_ENGINEER — Pre-sales technical resource. Eligible for commission plans but not bonus (bonus is for managers only).
• SALES_MANAGER — People manager. Eligible for manager bonus plans and MBO plans.
• PARTNER_RESELLER — Channel partner. Eligible for partner-specific commission plans with different rate structures.

Plan eligibility rules are often built into the IM system: a plan says "only assign to participants with POSITION_ID in (SALES_REP_WEST, SALES_REP_EAST, SALES_REP_CENTRAL)." This prevents accidentally assigning a field engineer to a top-tier executive bonus plan.

Importing Participants

Participants rarely start in SAP SuccessFactors IM. They come from an HR system (usually SAP SuccessFactors HCM, but sometimes SAP S/4HANA or a legacy system). The typical import flow:

Data Source Candidates

• SAP SuccessFactors HCM — Native integration. You can use the SAP SuccessFactors HCM connector or a scheduled API pull to feed employees into IM.
• SAP S/4HANA (PA-PD module) — Personnel administration. Requires a middleware connector (SAP Data Services, Talend, custom REST API).
• Legacy HR system — ADP, Workday, etc. Export to CSV, validate, then import via IM's flat file loader.

Typical Import Pattern

The SAP SuccessFactors HCM → SAP SuccessFactors IM feed usually runs nightly:

1. HCM system exports active employees: EMPLOYEE_ID, first/last name, hire date, manager EMPLOYEE_ID, cost center (maps to DEPARTMENT_ID).
2. Middleware maps EMPLOYEE_ID to PARTICIPANT_ID (often the same, or a concat of EMPLOYEE_ID + location code).
3. Load into a staging table, validate (check for nulls in required fields, check for duplicate EMPLOYEE_ID).
4. On success, merge staging data into CSC_PARTICIPANT, setting STATUS='ACTIVE' for new hires, STATUS='TERMINATED' for anyone not in the feed.
5. On validation failure, log errors and hold the import pending manual review.

Common Import Failures

-- 1. Missing required fields
SELECT COUNT(*) AS NULL_NAME_COUNT
FROM CSC_PARTICIPANT
WHERE NAME IS NULL;

-- 2. Duplicate EMPLOYEE_ID (should be unique)
SELECT EMPLOYEE_ID, COUNT(*) AS DUP_COUNT
FROM CSC_PARTICIPANT
WHERE STATUS = 'ACTIVE'
GROUP BY EMPLOYEE_ID
HAVING COUNT(*) > 1;

-- 3. Manager not found: MANAGER_ID points to non-existent participant
SELECT p1.PARTICIPANT_ID, p1.NAME, p1.MANAGER_ID
FROM CSC_PARTICIPANT p1
LEFT JOIN CSC_PARTICIPANT p2
  ON p2.PARTICIPANT_ID = p1.MANAGER_ID
WHERE p1.MANAGER_ID IS NOT NULL
  AND p2.PARTICIPANT_ID IS NULL;

Duplicate EMPLOYEE_ID is a critical error. It causes the pipeline to fail: when a credit comes in tagged with EMPLOYEE_ID, the system can't determine which participant it belongs to. Duplicates must be resolved in the source system (HR) before import.

Active vs Inactive: Status Management

A participant's status drives eligibility for plan processing:

• ACTIVE — In the organization, eligible for plans and calculations. Hire date <= today, TERMINATION_DATE is NULL or in the future.
• INACTIVE — Temporarily not eligible. Used for leave of absence, sabbatical, etc. The participant exists but is skipped by the pipeline.
• TERMINATED — Left the organization. TERMINATION_DATE set to last day of employment. Calculations stop on that date. Eligible for final period payout (proration).

The distinction between INACTIVE and TERMINATED matters for payroll:

• A terminated employee in their final period might be owed a prorated incentive (they earned commissions through day 50 of a 90-day period).
• An inactive employee (on leave) does not earn anything until reactivated.

Termination Best Practices

When an employee leaves:

1. Set TERMINATION_DATE to their last day.
2. Run the pipeline for their final period(s), allowing proration if the system supports it.
3. Update STATUS to 'TERMINATED' after final payroll is submitted.
4. Do NOT delete the participant from CSC_PARTICIPANT — you need the history for audits and chargeback handling.

Plan Assignment and Quota Allocation

Once participants are loaded, assign them to plans. This is done in CSC_PLAN_PARTICIPANT and CSC_QUOTA:

-- Which plans is each participant on this quarter?
SELECT
  cp.PARTICIPANT_ID,
  cp.NAME,
  cpa.PLAN_ID,
  ccomp.NAME             AS PLAN_NAME,
  ccomp.PLAN_TYPE,
  cpa.EFFECTIVE_START_DATE,
  cpa.EFFECTIVE_END_DATE,
  cq.PERIOD_ID,
  cq.QUOTA_AMOUNT
FROM CSC_PARTICIPANT cp
JOIN CSC_PLAN_PARTICIPANT cpa
  ON cpa.PARTICIPANT_ID = cp.PARTICIPANT_ID
JOIN CSC_COMP_PLAN ccomp
  ON ccomp.ID = cpa.PLAN_ID
LEFT JOIN CSC_QUOTA cq
  ON cq.PLAN_ID = cpa.PLAN_ID
  AND cq.PARTICIPANT_ID = cp.PARTICIPANT_ID
  AND cq.PERIOD_ID = '2026-Q2'
WHERE  cp.STATUS = 'ACTIVE'
  AND cpa.EFFECTIVE_START_DATE <= CURRENT_DATE
  AND cpa.EFFECTIVE_END_DATE >= CURRENT_DATE
ORDER BY cp.NAME, ccomp.NAME;

This query shows every active participant, which plans they're on right now, and their quota for Q2 2026. Notice the three-way join: participant → plan assignment → quota by period. A participant might have a base quota but it can be overridden per period (e.g., a new territory ramp has lower Q1 quota, then increases).

The Orphaned Participant Problem

This is the critical gotcha that catches implementations off-guard:

An orphaned participant is someone with CSC_PARTICIPANT record but no active plan assignment (CSC_PLAN_PARTICIPANT). They receive zero incentives, even if credits are posted in their name.

Why does this happen?

• New hires are added to CSC_PARTICIPANT but the assignment job hasn't run yet.
• A plan assignment has an EFFECTIVE_END_DATE that's already passed; a new assignment was supposed to start but wasn't created.
• Manual deletion of a plan assignment by accident.
• A participant's position type changed mid-period, but the old plan assignment wasn't ended and the new one wasn't created (overlap issues).

Find orphaned participants before each period close:

-- Participants with no active plan assignment (orphaned)
SELECT
  cp.PARTICIPANT_ID,
  cp.NAME,
  cp.STATUS,
  cp.POSITION_ID,
  COUNT(DISTINCT cpa.PLAN_ID) AS ACTIVE_PLAN_COUNT,
  cp.LAST_MODIFIED_DATE
FROM CSC_PARTICIPANT cp
LEFT JOIN CSC_PLAN_PARTICIPANT cpa
  ON cpa.PARTICIPANT_ID = cp.PARTICIPANT_ID
  AND cpa.EFFECTIVE_START_DATE <= CURRENT_DATE
  AND cpa.EFFECTIVE_END_DATE >= CURRENT_DATE
WHERE  cp.STATUS = 'ACTIVE'
GROUP BY cp.PARTICIPANT_ID, cp.NAME, cp.STATUS, cp.POSITION_ID,
         cp.LAST_MODIFIED_DATE
HAVING COUNT(DISTINCT cpa.PLAN_ID) = 0
ORDER BY cp.LAST_MODIFIED_DATE DESC;

Run this query weekly. The LAST_MODIFIED_DATE column tells you if this is a new problem (recently added participant) or an old one (stale assignment). Route findings to the plan administrator for correction before pipeline execution.

Quota Assignment: The CSC_QUOTA Table

Quotas are assigned at the participant + plan + period level:

-- Quota roll-up by department for 2026
SELECT
  cp.DEPARTMENT_ID,
  cpp.PERIOD_ID,
  ccomp.NAME             AS PLAN_NAME,
  COUNT(DISTINCT cq.PARTICIPANT_ID)
                         AS PARTICIPANTS_WITH_QUOTA,
  SUM(cq.QUOTA_AMOUNT)   AS TOTAL_DEPT_QUOTA,
  ROUND(AVG(cq.QUOTA_AMOUNT), 2)
                         AS AVG_QUOTA
FROM CSC_PARTICIPANT cp
JOIN CSC_QUOTA cq
  ON cq.PARTICIPANT_ID = cp.PARTICIPANT_ID
JOIN CSC_PLAN_PERIOD cpp
  ON cpp.PERIOD_ID = cq.PERIOD_ID
JOIN CSC_COMP_PLAN ccomp
  ON ccomp.ID = cq.PLAN_ID
WHERE  ccomp.NAME = '2026 Commission Plan'
  AND cp.DEPARTMENT_ID IS NOT NULL
GROUP BY cp.DEPARTMENT_ID, cpp.PERIOD_ID, ccomp.NAME
ORDER BY cp.DEPARTMENT_ID, cpp.PERIOD_ID;

This aggregation is useful for finance validation. If EMEA sales has 50 reps and a $100M annual quota, the average per rep is $2M — reasonable? If it's $500K, there's probably an import error. Validate quota totals against your financial plan before running the pipeline.

Position Types and Plan Eligibility Rules

Position types define who can be assigned to which plans. A common error is assigning a field engineer (who should earn commission) to a manager bonus plan (which requires team-level metrics):

-- Find participants assigned to plans they shouldn't be on
-- Example: field engineers shouldn't be on 'Manager Bonus' plans
SELECT
  cp.PARTICIPANT_ID,
  cp.NAME,
  cp.POSITION_ID,
  ccomp.NAME             AS PLAN_NAME,
  cpa.EFFECTIVE_START_DATE
FROM CSC_PARTICIPANT cp
JOIN CSC_PLAN_PARTICIPANT cpa
  ON cpa.PARTICIPANT_ID = cp.PARTICIPANT_ID
JOIN CSC_COMP_PLAN ccomp
  ON ccomp.ID = cpa.PLAN_ID
WHERE  cp.POSITION_ID LIKE 'FIELD_ENGINEER%'
  AND ccomp.NAME LIKE '%Manager Bonus%'
  AND cpa.EFFECTIVE_START_DATE <= CURRENT_DATE
  AND cpa.EFFECTIVE_END_DATE >= CURRENT_DATE;

Query like this to validate position/plan alignment. If you find mismatches, either end the assignment or correct the position_id.

Comparison with Callidus Commissions