What is SQL and Why Every ICM Practitioner Needs It

The Problem SQL Solves

Imagine you're an Incentive Compensation Manager at a mid-size enterprise. Your sales team is complaining that their Q1 2026 commissions are missing. You log into SAP SuccessFactors Incentive Management and start clicking through screens to find the data. You check participant records, filter by plan, check the results table, cross-reference compensation plans. After 30 minutes, you've manually checked 20 participants and found the issue: a data upload failed for a specific region, so their results never processed.

Now imagine if you could ask the database: "Show me all participants in the Northwest region who should have results in Q1 2026 but don't, ordered by expected earnings." That's SQL. It takes your question and transforms it into a precise data request that the database answers in milliseconds.

SQL is a language — not a programming language, but a query language. Its job is simple: let you describe what data you want, and the database finds it for you. You don't tell the computer how to search (which is what programming languages do). You describe what you want, and the database engine figures out the "how."

Why SAP SuccessFactors IM and Callidus Commissions Both Use SQL

Let's zoom out. SAP SuccessFactors Incentive Management (ICM) runs on SAP HANA Database. Callidus Commissions runs on Oracle Database. Both are relational databases. This means:

• All data is stored in tables (think: spreadsheets, but with enforced rules)
• Each row represents one record (one participant, one compensation plan, one result)
• Each column represents an attribute (NAME, PARTICIPANT_ID, RESULT_AMOUNT, etc.)
• Tables are connected via relationships (a participant ID in the RESULTS table points back to the PARTICIPANT table)

Both systems store the same kinds of data:

Notice the pattern: SAP SuccessFactors IM uses CSC_ prefix (Callidus SuccessFactors Commissions), and Callidus uses CS_ prefix. The table structures and column names are almost identical. Learn SQL on one system, and you can query the other immediately.

SQL is the language that queries these tables. Without SQL, you're stuck clicking through UI screens, reading one record at a time, unable to see patterns or aggregate results.

SELECT: The Fundamental Operation

SQL has four core operations:

• SELECT — Read data from a table
• INSERT — Add new rows to a table
• UPDATE — Change existing data in a table
• DELETE — Remove rows from a table

As an ICM practitioner, 95% of your SQL work is SELECT. You read, filter, summarize, and analyze data. The write operations (INSERT, UPDATE, DELETE) are handled by the ICM application itself, not by hand-written SQL. We'll focus entirely on SELECT.

Here's your first SQL statement, explained line by line:

SELECT *
FROM CSC_PARTICIPANT;

Breaking this down:

• SELECT — "I want to retrieve data"
• * — "All columns"
• FROM — "from this table"
• CSC_PARTICIPANT — the participant table in SAP SuccessFactors IM

This query returns every row and every column in the CSC_PARTICIPANT table. In Callidus Commissions, the same query would be:

SELECT *
FROM CS_PARTICIPANT;

Identical syntax, different table name. That's the pattern you'll see throughout this learning path.

What You Can Do With SELECT

SELECT is powerful because you can layer conditions and operations on top of it:

SELECT
  PARTICIPANT_ID,
  NAME,
  STATUS
FROM   CSC_PARTICIPANT
WHERE  STATUS = 'ACTIVE'
  AND   COUNTRY = 'US'
ORDER BY NAME ASC;

This query:

• Picks specific columns: You only get PARTICIPANT_ID, NAME, and STATUS (not every column)
• Filters rows: WHERE STATUS = 'ACTIVE' AND COUNTRY = 'US' means only US-based active participants
• Sorts results: ORDER BY NAME ASC sorts alphabetically by name

In less than a second, the database finds all US-based active participants, retrieves their three columns, and sorts them by name. Try doing that manually on 50,000 participants.

JOINs: Combining Tables

SAP SuccessFactors IM and Callidus Commissions store data across multiple tables. Participants are in one table. Results are in another. Compensation plans are in a third. SQL lets you combine them.

Here's a real question: "What is the total earned amount for each participant in Q1 2026?" To answer this:

• You need the PARTICIPANT table (to get names)
• You need the RESULTS table (to get earnings amounts)
• You need a way to connect participants to their results

That connection is a JOIN. A JOIN combines rows from two tables based on a matching condition:

SELECT
  p.NAME,
  p.PARTICIPANT_ID,
  SUM(r.RESULT_AMOUNT) AS TOTAL_EARNED
FROM     CSC_PARTICIPANT p
JOIN     CSC_RESULTS    r ON r.PARTICIPANT_ID = p.PARTICIPANT_ID
WHERE    r.PERIOD_ID = '2026-Q1'
GROUP BY p.NAME, p.PARTICIPANT_ID
ORDER BY TOTAL_EARNED DESC;

This introduces new concepts (GROUP BY, aggregate functions like SUM, aliases like p and r) that we'll dive into in later lessons. For now, the key insight: the JOIN connects the PARTICIPANT table to the RESULTS table using the condition r.PARTICIPANT_ID = p.PARTICIPANT_ID. This says: "Match rows from the RESULTS table where the PARTICIPANT_ID matches rows in the PARTICIPANT table."

SELECT vs DML: Read vs Write

SQL has two broad categories of operations:

• SELECT (DML Read): Retrieves data. No risk of damage. Safe to run on production.
• INSERT, UPDATE, DELETE (DML Write): Modifies data. High risk. Never run on production without approval.

SELECT is your safe zone. You cannot accidentally break data by reading it. This is why many ICM practitioners get SELECT access to production databases — they can investigate issues without risk.

Why This Matters for You

Here's why SQL is essential for ICM work:

• Debugging: When a commission is missing, you can write a query to check if the data exists in the database or if the calculation itself failed
• Validation: Before kicking off a compensation period, query the data to ensure all participants, plans, and quotas are loaded correctly
• Auditing: When someone asks, "Did this person get paid?", you can prove it with a query instead of guessing
• Reporting: Sophisticated ICM reporting often requires custom queries that the UI can't produce
• Migration: When moving from Callidus Commissions to SAP SuccessFactors IM (or vice versa), validation queries are critical
• Efficiency: Answering a data question takes seconds with SQL. Manually checking records takes hours.

You don't need to write complex queries. The next lessons will teach you the patterns you'll actually use in production. You're not training to be a database administrator. You're training to be an ICM practitioner who understands data.

SAP HANA vs Oracle: The Same Foundation

We mentioned that SAP SuccessFactors IM uses SAP HANA Database and Callidus Commissions uses Oracle Database. Don't let that intimidate you. The foundational SELECT syntax is identical on both:

You'll write one SELECT statement and run it on both systems without modification. The differences matter when you get into advanced territory (window functions, procedural SQL), and we'll call them out explicitly. For now, what you learn applies to both.

What Comes Next

In Lesson 02, we'll build on this foundation. You'll learn:

• How to select specific columns instead of all columns (*)
• The WHERE clause and its operators (=, !=, >, <, BETWEEN, IN, LIKE)
• NULL handling and why it's critical in ICM
• ORDER BY and LIMIT to control result sets
• AND/OR logic to combine multiple conditions

By the end of Lesson 02, you'll be able to write production-ready queries to filter participants, find missing data, and validate compensation plans.