SAP Analytics Cloud and the IM Reporting Layer

Embedded Analytics is often described as "built-in reporting" or "reporting inside IM," but the full story is more nuanced. Embedded Analytics is actually a purpose-built instance of SAP Analytics Cloud (SAC)—SAP's cloud BI platform. To understand Embedded Analytics, you need to understand SAC and the three-layer architecture that underpins it: SAP HANA Database, Calculation Views, and SAP Analytics Cloud itself.

What is SAP Analytics Cloud?

SAP Analytics Cloud is SAP's cloud-native BI and analytics platform. It is a SaaS offering that handles dashboarding, reporting, analytics, and planning workflows. SAC is a general-purpose BI tool—you can connect it to any data source (Salesforce, S/4HANA, Datasphere, Excel, etc.) and build dashboards for any use case.

In the context of SAP SuccessFactors IM, SAC appears as Embedded Analytics—a pre-configured instance of SAC that is connected to the IM HANA Database and pre-loaded with IM-specific content (standard stories, calculation views, templates). From the user's perspective, it is "built-in" to IM because they access it from within the IM interface. From the technical perspective, it is a SAC instance that is tailored for IM.

The distinction matters because it means Embedded Analytics is not a separate product—it is SAC in a specific context. If you learn SAC, you can build custom Embedded Analytics stories. If you are already familiar with SAC, you will recognize the interface, terminology, and capabilities when you open Embedded Analytics in IM.

The Three-Layer Architecture

The reporting stack for SAP SuccessFactors IM has three distinct layers:

Layer 1: SAP HANA Database (CSC_ Tables)

At the bottom is the system of record—SAP HANA Database. When the IM calculation engine runs a period, it writes results to CSC_ tables. These are normalized relational tables:

• CSC_RESULTS — one row per participant/period/plan with calculation results (result amount, incentive amount, attainment %, etc.).
• CSC_PARTICIPANT — participant master data (name, manager, territory, cost centre, effective dates).
• CSC_COMP_PLAN — plan definitions.
• CSC_QUOTA — quota amounts by participant/period/plan.
• CSC_PERIOD — period definitions (start/end dates, fiscal calendar).
• CSC_PLAN_PARTICIPANT — the join table mapping participants to plans and assignment dates.

These tables are optimized for the calculation engine's operational needs—fast transactional writes, referential integrity, normalized structure. They are not optimized for reporting. That is why Layer 2 exists.

Layer 2: Calculation Views

Calculation Views are SAP HANA modelling artefacts—pre-built query objects that sit on top of the raw CSC_ tables. They join the raw tables, calculate derived fields, and set aggregation rules. Think of a Calculation View as a saved query that is optimized for reporting consumption.

For example, the "Quota Attainment" Calculation View might do the following:

• JOIN CSC_RESULTS + CSC_PARTICIPANT + CSC_QUOTA + CSC_PERIOD
• CALCULATE ATTAINMENT_PCT = (RESULT_AMOUNT / QUOTA_AMOUNT * 100)
• CALCULATE ATTAINMENT_BAND = CASE WHEN ATTAINMENT_PCT >= 120 THEN 'ABOVE TARGET' ...
• SET AGGREGATION: Result Amount aggregates as SUM, Participant Name does not aggregate (grouping dimension)

Calculation Views are stored as HANA objects in a schema like _SYS_BIC or _SYS_IM. They appear in HANA Studio and HANA Database Explorer just like tables do. You can query them directly with SQL, use them as data sources in Embedded Analytics, or expose them via ODBC for external BI tools.

Why do we need Calculation Views if we can query CSC_ tables directly? Performance and semantics. A Calculation View pre-defines the reporting model—which fields are dimensions (grouping), which are measures (aggregating), what the natural joins are. HANA's query engine can optimize a query against a Calculation View better than it can optimize the same query written manually. Also, Calculation Views are the contract between the data team and the reporting team: the data team maintains the Calculation View, and reporting users consume it without needing to understand the underlying table structure.

Layer 3: SAP Analytics Cloud / Embedded Analytics

At the top is SAC (or Embedded Analytics, which is SAC in an IM context). This is where users build and consume dashboards. Users drag fields from Calculation Views onto a canvas, create charts and tables, and set filters. SAC translates the user's choices into a SQL query against the Calculation View, executes it, and displays the results.

Understanding Calculation Views

Calculation Views are central to how Embedded Analytics works, so it is worth understanding them in more detail.

A Calculation View is a HANA object that wraps a query. When you create a Calculation View, you define:

• Input sources — which tables or views the Calculation View reads from (e.g., CSC_RESULTS, CSC_PARTICIPANT).
• Join logic — how the input sources are joined (e.g., CSC_RESULTS JOIN CSC_PARTICIPANT ON PARTICIPANT_ID).
• Calculated columns — derived fields computed from the input sources (e.g., ATTAINMENT_PCT = RESULT_AMOUNT / QUOTA_AMOUNT * 100).
• Attributes and measures — which columns are dimensions (grouping fields) and which are measures (numeric fields that aggregate).
• Filters and semantics — what the default aggregation behavior should be (SUM, COUNT, AVG, MAX, MIN, or no aggregation).

Once a Calculation View is created and activated, you can query it like a table:

-- Query a calculation view directly from HANA
-- (It appears in schema _SYS_BIC or similar)
SELECT
  PARTICIPANT,
  MANAGER,
  PLAN,
  PERIOD_ID,
  QUOTA,
  RESULT,
  ATTAINMENT_PCT,
  ATTAINMENT_BAND
FROM _SYS_BIC.IMV_QUOTA_ATTAINMENT  -- This is a Calculation View
WHERE PERIOD_ID = :period_id
  AND STATUS = 'APPROVED'
ORDER BY ATTAINMENT_BAND DESC, ATTAINMENT_PCT DESC;

Embedded Analytics uses Calculation Views the same way—it queries them and displays the results. When you drag a Calculation View field onto a story in Embedded Analytics, SAC translates that into a query. The beauty of Calculation Views is that users (and tools like SAC) do not need to understand the underlying join logic or table structure. They just select fields and SAC handles the rest.

The Data Flow: From Calculation to Dashboard

Here is the complete data flow end-to-end:

1. Calculation run. The IM calculation engine completes a period calculation. It computes participant results, incentives, attainment percentages, and writes everything to CSC_RESULTS and related tables.
2. HANA persistence. CSC_RESULTS is persisted in SAP HANA Database (the system of record). Data is now queryable from HANA.
3. Calculation View refresh. The pre-built Calculation View (e.g., IMV_QUOTA_ATTAINMENT) sits on top of CSC_RESULTS. When you query the Calculation View, HANA executes the join and calculation logic defined in the view.
4. SAC query execution. A user opens Embedded Analytics and views a pre-built or custom story. SAC constructs a query against the Calculation View based on the story definition (which fields, what filters, what aggregations). SAC sends this query to HANA.
5. Query result. HANA executes the query and returns results. HANA returns results to SAC in milliseconds (or seconds if the result set is very large).
6. Rendering. SAC renders the results in the browser—a chart, a table, a KPI tile. The user sees the dashboard.

The key insight: there is no batch process, no ETL, no nightly load. The data flows from the calculation engine → HANA → Calculation View → SAC query → user's browser. It is synchronous and live.

SAP Analytics Cloud Terminology

When you work with Embedded Analytics, you encounter SAC terminology:

Connection Types: Live (DirectQuery) vs Import

When you connect SAC (or Embedded Analytics) to a data source, you choose a connection type. This matters for performance and data freshness.

DirectQuery (Live Connection)

With DirectQuery, SAC sends a live query to HANA every time a user interacts with a widget. The user filters, the widget updates, SAC queries HANA again, and results appear in milliseconds. The data is always fresh—what is in HANA right now is what the user sees.

DirectQuery is the default for Embedded Analytics in IM because IM data changes frequently (results are updated, participants are added/removed, quotas are adjusted). Users expect to see the latest numbers.

The downside: if the query is complex or the result set is large, HANA query execution can be slow, and the user waits. But for most IM reports (quota attainment, earnings distribution, pipeline monitoring), queries are simple and fast.

Import (Copied Data)

With Import, SAC pulls a snapshot of data from HANA and stores it in SAC's database. All queries run against the copy. The advantage is speed—queries against SAC's database are often faster than queries against HANA. The disadvantage is staleness—the data is only as fresh as the last import. If you run an import at 8 AM and a user views the dashboard at 2 PM, they are looking at 6-hour-old data.

Import connections are useful for external data sources (Salesforce, S/4HANA) or when HANA queries are expensive. For IM, avoid Import unless you have a specific reason (e.g., you are combining IM data with external data and want to avoid too many HANA queries).

How SAP Analytics Cloud Fits in the SAP SuccessFactors Ecosystem

SAP SuccessFactors is a suite of cloud HR and talent management applications. Embedded Analytics appears in several SuccessFactors modules:

• SuccessFactors Incentive Management (IM) — the focus of this learning path. Reports on quota attainment, incentive earnings, pipeline runs, and plan coverage.
• SuccessFactors Compensation Management — salary planning and adjustments. Analytics on merit increases, pay equity, compensation bands.
• SuccessFactors Performance Management — goal and review data. Analytics on goal completion rates, performance distribution, engagement scores.
• SuccessFactors Recruiting — recruiting funnel and metrics. Analytics on time-to-hire, cost-per-hire, offer acceptance rates.

Each module has its own Embedded Analytics instance, pre-configured with module-specific calculation views and pre-built stories. The underlying technology is the same—SAC. The data sources are different (Compensation data, Performance data, Recruiting data).

Extending Embedded Analytics: Custom Calculation Views and Stories

SAP ships Embedded Analytics with pre-built content, but organizations often need custom reporting. You have two paths:

Path 1: Custom stories built on existing Calculation Views. If the pre-built Calculation Views have the fields you need, you can create a custom story in SAC without writing code. You drag fields onto a canvas, set up filters and visualizations, and publish the story. This is the path for business analysts and self-service reporting.

Path 2: Custom Calculation Views and stories. If the pre-built Calculation Views do not have the data you need, you create a custom Calculation View in HANA, then build a story on top of it. This is the path for technical teams and data engineers. You need HANA development skills (SQL, the Calculation View designer in HANA Studio).

Most implementations start with Path 1, then move to Path 2 for specialized reporting. The separation of concerns is clean: data engineers own Calculation Views, business analysts build stories.

Key Takeaways

• SAP Analytics Cloud (SAC) is the underlying BI platform. Embedded Analytics is SAC configured for IM.
• The three-layer architecture is HANA Database (CSC_ tables) → Calculation Views → SAP Analytics Cloud (stories and dashboards).
• Calculation Views are pre-built query objects that join CSC_ tables and define the reporting data model. Embedded Analytics stories query calculation views, not raw tables.
• DirectQuery (live connection) is the right choice for Embedded Analytics in IM. Queries run in real time against HANA. Data is always fresh.
• SAC terminology: Stories (dashboards), Pages (tabs), Widgets (charts/tables), Dimensions (grouping fields), Measures (numeric fields), Data Sources (connections).
• You can extend Embedded Analytics with custom stories (using existing Calculation Views) or custom Calculation Views (for new data models).