JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 19, 2026 · 15 min read

SAP SF Route Map

Route Map is the master data object that defines a reusable, ordered sequence of approval workflow steps — such as Self-rating, Manager Rating, Calibration, and Final — along with each step’s approver-resolution method, governing how a launched review form (or, in real-world practice, a goal plan) moves from launch through to completion. It is configured in the Goal & Performance Configuration sub-block of Phase 2 (Permission & System Configuration), and per the module’s Setup Flow its only listed prerequisite is Permission Role, not Performance Form Template or Goal Plan Template — a distinction confirmed independently against the SuccessFactors Master Data Landscape in Section 1.3 below. This article covers what a Route Map is, its common step-pattern variants, how it sits as a standalone object in the Talent & Compensation zone of the landscape with a single reference into the Permission & Time zone, and every field an Admin Center consultant configures for it.

Part 1: Route Map — Core Concepts (All Modules)#

1.1 What Is the Route Map?#

Route Map is a client-level (tenant-level) foundation object that carries no employee data of its own — it defines the shape of an approval workflow (its ordered steps and each step’s approver-resolution logic), not any single employee’s actual progress through that workflow. A launched form or plan snapshots the Route Map’s step sequence at launch time and tracks each employee’s individual movement through it separately; the Route Map itself stays a reusable, versioned configuration object.

1.2 Route Map Step-Pattern Variants#

A Route Map’s step pattern is not a cosmetic choice — it directly determines how many approval hand-offs a launched form goes through, whether calibration is enforced before a rating is finalized, and how long a full review cycle realistically takes to close. Over-building the step sequence for a lightweight checkpoint frustrates raters with unnecessary hand-offs; under-building it for a compensation-feeding annual review skips a calibration step management actually needs.

Design principle: match a Route Map’s step count and complexity to the review’s actual purpose — a lightweight checkpoint route map with a forced Calibration step adds friction with no corresponding governance benefit, while a compensation-feeding annual review route map without Calibration lets ratings finalize without the cross-manager consistency check the compensation process typically depends on.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Route Map sits in the tenant-level “Talent & Compensation” zone of the SuccessFactors Master Data Landscape (Zone D), but — unlike Rating Scale, Goal Plan Template, and Performance Form Template, which form a single serial chain — it is a standalone client-level object with no solid parent-child connector to any other Zone D node. Its only connection in the landscape is a single outbound cross-zone reference into Zone C (Permission & Time):

Client (SuccessFactors Instance)
   │
   ├── Route Map "RM_Std" — Self → Manager → Calibration → Final  ← this article
   │      │
   │      └── references ──> Permission Role "PR_ESS" — Employee Self-Service  (Zone C, see SF-A03-02)
   │
   └── Performance Form Template "PFT_Annual2024" — Annual Review, 4-section, of GPT_2024
          (same Zone D; no landscape data-model connector to Route Map — real-world usage only, see Section 1.4)

MANDATORY landscape verification note: the module Master.md’s ER Diagram nests Route Map as a child of Performance Form Template (“Rating Scale → Goal Plan Template / Performance Form Template → Route Map”), with a separate annotation “Route Map ←── Permission Role” placed beside it in the same diagram block. The Setup Flow, however, lists only one prerequisite for Route Map: “21. Route Map ← (Permission Role)” — Permission Role, not Performance Form Template, is Route Map’s sole listed dependency. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html, Zone D, verified directly against the HTML/SVG source this session, consistent with the independent verification already recorded on SF-A03-07/08/09) resolves this the same way as the Setup Flow, not the ER Diagram: Route Map (RM_Std) is placed as a standalone Row 4 node (top:1295px) in Zone D, and scanning every <line> element in the SVG confirms no connector originates at or terminates on that node — the two Zone D solid chains stop one row short of it (RS_5pt → GPT_2024 → PFT_Annual2024 at x=1060 ends at y=1150; CP_Merit2024 → CT_Merit → ER_FT1Y at x=1360 ends at y=1245). The only element attached to the Route Map node at all is a ref-chip reading “↗ PR_ESS” inside its own card, which the Zone D legend defines explicitly as “Route Map references a Permission Role in Zone C” — a cross-zone reference, not a parent-child connector, and not a connection to Performance Form Template, Goal Plan Template, or Rating Scale. Route Map’s only data-model relationship recorded in this landscape is therefore to Permission Role — see Section 1.4. In real-world SuccessFactors deployments, Route Maps are still typically selected and bound as part of Performance Form Template (and, for goal-approval workflows, Goal Plan Template) setup — see Section 2.4 — but per this landscape, that binding is a launch-time template selection, not a stored data-model connector, which is why it is described here as usage rather than integration.

Design principle: because Route Map — like Permission Role before it — carries no employee data of its own and has no true parent object in the data model, its own hierarchy position is intentionally shallow: a single client-level node whose only structural relationship is an outbound reference to Permission Role for approver resolution. The complexity that matters to a consultant lives entirely inside the Route Map’s own step configuration (Part 2), not in additional hierarchy nesting.

1.4 Integration with Other Master Data Objects#

Route Map has exactly one confirmed data-model relationship in the landscape — an outbound reference to Permission Role — despite sitting visually inside the same Talent & Compensation zone as the Rating Scale → Goal Plan Template → Performance Form Template chain and the Compensation-chain objects. Consultants coming from the ER Diagram’s nesting of Route Map under Performance Form Template should treat that nesting as a real-world usage description, not a landscape-verified connector; see Section 1.3 for the full verification.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Route Map Definition (Core Identification)#

Route Map Definition is the minimum record a Route Map needs to exist — it is what every Performance Form Template’s Route Map Binding field (SF-A03-09, Section 2.4) and every step-level Permission Role reference resolves back to.

2.2 Workflow Step Configuration#

Workflow Step Configuration is the repeatable child record — one row per step — that actually defines the ordered path a launched form or plan moves through, and is where the step-pattern variants from Section 1.2 are physically built.

2.3 Step-Level Approver Assignment#

Step-Level Approver Assignment is where each step’s who is determined — the field group that implements the landscape’s confirmed Route Map → Permission Role reference (Section 1.3/1.4).

2.4 Usage in Template Binding#

A Route Map itself contains no employee data and is not launched on its own — it only becomes active once a Performance Form Template (or, in real-world practice, a Goal Plan Template) is launched with this Route Map bound to it. This section covers how that binding works in practice and repeats, deliberately, the honesty distinction established in Section 1.3: this is real-world usage, not a verified landscape data-model connector.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction