JinJin48

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

July 19, 2026 · 15 min read

SAP SF Work Schedule

Work Schedule is the master data object that defines the recurring weekly working-time pattern — which weekdays are scheduled working days and how many hours apply to each — for a workforce segment, and binds that pattern to exactly one Holiday Calendar so its non-working dates are excluded automatically. It is the second and final object in the Time Configuration chain of Phase 2 (Permission & System Configuration): where Holiday Calendar (SF-A03-03) supplies the dates that are never working days regardless of schedule, Work Schedule supplies the actual weekly working-hours template that those dates get subtracted from — and the combined result is the input Time Profile bundles for employee assignment. This article covers what a Work Schedule is, its weekly-pattern variants (standard full-time, shift/alternating, part-time, country-specific), how it sits alongside the parallel Permission Management and Time Type chains in the same landscape zone, and every field an Admin Center consultant configures for it.

Part 1: Work Schedule — Core Concepts (All Modules)#

1.1 What Is the Work Schedule?#

Work Schedule is a client-level configuration object that carries two pieces of information at once: a per-weekday pattern of scheduled working hours, and a required reference to one Holiday Calendar whose dates are subtracted from that pattern. Neither half is meaningful alone — a weekly pattern without a bound calendar has no way to know which weekdays are actually holidays, and a Holiday Calendar without a Work Schedule referencing it never gets read by anything. Together the two form the single source of truth that Time Profile, Time Sheet, and Time Off all depend on to determine whether a given date counts as a scheduled working day for a given employee.

1.2 Work Schedule Pattern Variants#

Not every workforce segment follows the same weekly rhythm, and modeling that difference as one overloaded schedule instead of separate, purpose-built Work Schedules is a routine cause of incorrect scheduled-hours baselines showing up first as unexplained overtime or Time Sheet variances.

Design principle: build a Work Schedule around a genuinely distinct weekly-hours template, not around an individual employee — it is a reusable pattern, not an assignment record. Individual-level variation (which schedule an employee is on today) belongs to Time Profile and Job Information, not to a one-off copy of the schedule itself.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Work Schedule sits in the same tenant-level “Permission & Time” zone of the SuccessFactors Master Data Landscape as Permission Group / Permission Role (SF-A03-01/02) and its own upstream input, Holiday Calendar (SF-A03-03) — one of three parallel, independent client-level configuration chains bundled into that zone (Permission Management; Holiday Calendar → Work Schedule; Time Type → Time Account Type, tied together by Time Profile). This article’s own object is the second and final node of the Time Configuration chain; the other two chains exist in the same landscape zone but belong to sibling articles:

Client (SuccessFactors Instance)
   │
   ├── Permission Group "PG_Manager" — Managers, Direct Reports  (see SF-A03-01)
   │      │
   │      └── Permission Role "PR_ESS" — Employee Self-Service, of PG_Manager  (see SF-A03-02)
   │
   ├── Holiday Calendar "HC_JP2024" — Japan 2024, 16 holidays  (see SF-A03-03)
   │      │
   │      └── Work Schedule "WS_JP_Std" — JP Standard, 40H/week, of HC_JP2024
   │
   └── Time Type "TT_Annual" — Annual Leave, category  (Time Configuration chain, see SF-A03-05)
          │
          └── Time Account Type "TAT_Annual" — 20 days, 5-day carryover, of TT_Annual

Time Profile "TP_JP_Std" — JP Standard, Work Schedule + Time Account Type bundle  (see SF-A03-06)
   ├── assigned to ──> Work Schedule "WS_JP_Std"
   └── assigned to ──> Time Account Type "TAT_Annual"

MANDATORY landscape verification note: the module Master.md’s ER Diagram labels the Holiday Calendar → Work Schedule relationship explicitly as “1:N” — a single Holiday Calendar can be, and typically is, referenced by many Work Schedules (e.g. every schedule variant covering employees in Japan shares the same “HC_JP2024” calendar), never the reverse. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html, Zone C) draws this as a single solid parent-child connector — HC_JP2024 → WS_JP_Std — representing one instance of that 1:N relationship, not a claim that a calendar owns exactly one schedule (see SF-A03-03, Section 1.3, for the identical note from the Holiday Calendar side). On the downstream side, the ER Diagram shows a plain arrow from Work Schedule into Time Profile (Work Schedule → Time Profile ←── Time Account Type), and the landscape renders this as the purple dashed “assigned to” arrow running from TP_JP_Std up to WS_JP_Std — a Time Profile references one Work Schedule as a required input, and the same Work Schedule is routinely reused across many Time Profiles covering the same weekly pattern. See Section 1.4 and 2.4 for how both directions of reuse play out in practice.

Design principle: Work Schedule is the object where the two upstream chains of Time Configuration converge into one usable pattern — it does not itself have organizational sub-levels; all of its structural complexity lives in its own field configuration (the bound calendar plus the per-weekday hours pattern, Part 2), not in additional hierarchy nesting.

1.4 Integration with Other Master Data Objects#

Work Schedule is the pivot point of the Time Configuration chain: it consumes Holiday Calendar on the input side, and every downstream object that needs to know “is this date a scheduled working day” resolves back to it, directly or through Time Profile.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

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

2.1 Schedule Definition (Core Identification)#

Schedule Definition is the minimum record a Work Schedule needs to exist — it is what every Time Profile’s schedule picker, and every reference to the schedule elsewhere in the system, resolves back to.

2.2 Holiday Calendar Binding#

Holiday Calendar Binding is the field group that connects a Work Schedule’s own weekly pattern to the set of dates it must exclude — without a valid binding here, the weekly pattern in Section 2.3 has no way to know which weekdays are actually holidays.

2.3 Weekly Working-Time Pattern#

The Weekly Working-Time Pattern is the actual payload of a Work Schedule — the per-weekday template that, combined with the bound calendar’s excluded dates, produces the final scheduled-hours result Time Sheet and Time Off both read.

Prerequisite: because the Weekly Working-Time Pattern only produces a correct result once combined with a valid, Active Holiday Calendar binding (Section 2.2), always build and verify the calendar binding before finalizing the per-weekday hours — testing the pattern against an unbound or wrong calendar produces scheduled-hours results that look plausible but are silently incorrect on holiday dates.

2.4 Usage in Time Profile Assignment#

A Work Schedule itself performs no employee-level calculation — it only becomes meaningful once bound into a Time Profile alongside a Time Account Type. This section covers how that binding works and where the most common maintenance gaps occur.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction