Schedule Build and Publish (generic process)

Schedule Build and Publish (generic process) is the generic process card, GP-201, for the recurring process by which a workforce function turns the requirement for a scheduling period into a schedule of record: it takes the requirement in, confirms the shift catalogue and the rule set, runs the bid or preference window, generates and assigns, checks the result for coverage, fairness and compliance, approves it, publishes it with the notice period the jurisdiction or contract requires, and runs the exception window that closes before the schedule passes to maintenance. The card owns the process at L1 and L2. It does not own the method inside any one step: the five-step sequence from requirement to publication is on Employee Scheduling, the mathematics of generation on Schedule Generation and Schedule Optimization, the catalogue on Shift Design, the allocation mechanisms on Schedule Bidding and Preference Based Scheduling, and the activity codes the schedule is written in on Activity-Code Consistency. It is part of Process Standardization and sits under the scheduling section of the function catalog in Anatomy of a ROC Standard.

The process matters to a standards committee because publication is the moment a schedule stops being a plan and becomes a commitment: to the people on it, whose notice period starts at the timestamp; to the real-time function, which measures adherence against the version published; and in a growing number of jurisdictions to a regulator, for whom a change after publication carries a payment.

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3) with the facts a standards committee needs before any step is drawn. Local values are held by the deploying function and marked SET LOCALLY.

Field	Generic value
Card	GP-201 · local card id assigned by the standards committee at deployment
Class	strategic, in the catalog's four-class vocabulary (strategic · real-time · both · supporting): a planned batch process with lead time, never run inside the day
Trigger	the release of the period's requirement by GP-103 on the build calendar; an event-driven rebuild when a new-hire class lands or a unit is restructured
Cadence	once per scheduling period (one or two weeks is typical [A]); the bid cycle on its own longer calendar (SET LOCALLY)
Scope in	requirement intake; catalogue and rule-set confirmation; the bid or preference window; generation and assignment; the three quality checks; approval; publication; the exception window
Scope out	the requirement (GP-103 and Capacity Planning Cycle); the optimisation method (Schedule Optimization); change after the exception window (GP-202 and Real-Time Schedule Adjustment); the allotment (GP-203); self-scheduled claims (GP-204)
Inputs	the interval requirement by skill group; the roster with contract hours, approved time off and the training calendar; the shift catalogue; bids or preferences; the rule set in force; the activity-code dictionary
Outputs	the published schedule as version 1 of record with its timestamp and notice period; the coverage report against the requirement; the fairness report; the compliance check result; the exception log
Upstream	GP-103; GP-203; GP-505 for the skill mix; Shift Design; the HR partner for contract terms; the definitions register
Downstream	GP-202, which takes the version active at window close; GP-303, which measures against the version active; GP-301; payroll and time systems; GP-602
Resources	a scheduling engine; a roster system of record; a bid or preference portal; the rule register; the activity-code dictionary. Platforms are named at L3, never here
Decision points	is the catalogue adequate to the requirement's shape; does coverage sit within the band; does the fairness report sit within the band; does the compliance check pass; approve to publish; grant or defer an exception
Authority tier	the build, the coverage report and the fairness report at tier 1 (the scheduler seat inside guardrails, the fairness band read by the scheduling lead); the compliance check owned by the compliance lead; approval to publish at tier 3, because publication starts the notice period; a schedule that cannot reach the coverage band, or a works-council objection, resolves at tier 4
Risk and compliance flags	notice-period statutes and predictability pay; rest, maximum-hours and break rules as hard constraints, never after-the-fact checks; collective-agreement order in bids; the publication timestamp as an auditable record; retention of every version
Variant-prone steps	the notice period and the change premium; the allocation mechanism; a review step before publication; the publication channel; the length of the exception window
Automation candidates	eleven L2 sub-steps in seven groups (listed below)

L1 flow

Decision steps are questions. Owners are seats.

1. Receive the period's requirement by interval and skill group and reconcile it to the plan of record — scheduler.
2. Refresh the availability base: roster roll-forward, contract hours, approved time off, training and meeting calendar — scheduler.
3. Is the shift catalogue adequate to the requirement's shape? If not, raise a catalogue change through Shift Design before building — scheduling lead.
4. Confirm the rule set in force for the period: statutory, contractual and local parameters — scheduling lead, with the compliance lead.
5. Open the bid or preference window on the calendar and close it — scheduler.
6. Generate the schedule from the catalogue against the requirement — scheduler.
7. Assign named staff by the allocation mechanism in force — scheduler.
8. Does coverage meet the requirement within the band in every interval? If not, iterate steps 6 and 7, or raise the residual gap to the capacity planner — scheduler.
9. Does the fairness report sit within the band for the distribution of undesirable shifts and preference satisfaction by cohort? — scheduling lead.
10. Does the compliance check pass on rest, maximum hours, breaks and the collective-agreement rules? A failing schedule is never published — compliance lead.
11. Approve the schedule for publication — operations manager (tier 3).
12. Publish with the notice period, record the timestamp, and mark the result version 1 of record — scheduler.
13. Run the exception window; resolve errors as new versions, defer hardship exceptions to maintenance, close the window and hand the version active at window close to GP-202 — team lead and scheduler.

L2 step table

Thresholds, calendars and system names are L3 values marked SET LOCALLY. Durations are typical [A] unless marked.

Step	Sub-step	Owner (seat)	Inputs	Outputs	Duration	Automation candidate	Documentation join key
1	Load the requirement and check it reconciles to the plan of record and the definitions register	scheduler	requirement file; plan of record	reconciled requirement; discrepancy note	half a business day	Y	201-01a
1	Raise a discrepancy outside the band to the capacity planner	scheduler	discrepancy note	resolution or accepted variance	SET LOCALLY	N	201-01b
2	Roll the roster forward: starters, leavers, contract changes	scheduler	roster of record	availability base	half a business day	Y	201-02a
2	Apply approved time off and the training and meeting calendar	scheduler	allotment approvals; calendars	net availability	included above	Y	201-02b
3	Compare the catalogue's coverage curve to the requirement's shape	scheduling lead	catalogue; requirement	adequacy finding	half a business day	Y (the comparison)	201-03a
3	Raise a catalogue change where inadequate	scheduling lead	adequacy finding	change request to Shift Design	SET LOCALLY	N	201-03b
4	Confirm statutory, contractual and local parameters in force	scheduling lead; compliance lead	rule register; variant register	rule set for the period	one business day	N	201-04a
5	Open the window, notify, close on the calendar	scheduler	catalogue; eligible roster	bids or preferences	SET LOCALLY	Y	201-05a
6	Run generation against the requirement and the rule set	scheduler	net availability; catalogue; rule set	candidate schedule	one business day	Y (already an engine; the candidate is the check loop)	201-06a
7	Assign named staff by the allocation mechanism	scheduler	candidate schedule; bids	assigned schedule	included above	Y	201-07a
8	Produce the coverage report by interval and skill group	scheduler	assigned schedule; requirement	coverage report	minutes	Y	201-08a
8	Gap outside the band: iterate or escalate the residual	scheduler; capacity planner	coverage report	revised schedule or escalation	SET LOCALLY	N	201-08b
9	Produce the fairness report by cohort	scheduling lead	assigned schedule; history	fairness report	minutes	Y	201-09a
9	Fairness outside the band: re-weight and re-run, or accept with a stated reason	scheduling lead	fairness report	decision record	SET LOCALLY	N	201-09b
10	Run the compliance check as hard constraints	compliance lead	assigned schedule; rule set	pass or fail with the failing rows	minutes	Y	201-10a
11	Review the three reports and approve or return	operations manager	the three reports	approval record	half a business day	N	201-11a
12	Publish on the channel, stamp the time, set version 1	scheduler	approved schedule	version 1 of record; publication record	minutes	Y	201-12a
13	Receive and triage exceptions: error, hardship, other	team lead	exception requests	triaged log	the window, SET LOCALLY	N	201-13a
13	Correct errors as a new version; defer hardship to GP-202	scheduler	triaged log	version n; handover note	included above	N	201-13b

Variants

The known variant classes for this process, recorded per Standard and Variant in Process Documentation:

• Statutory. The length of the notice period and the change premium that follows it are parameters of step 12, marked SET LOCALLY, as are rest, maximum-hours and break rules in step 10. A jurisdiction whose works council holds a co-determination right over the distribution of working time inserts a review step between approval and publication; the works-council liaison owns the step, the function head approves the variant, and the variant takes a row.
• Contractual. A collective agreement that fixes the allocation order parameterizes step 7 and takes no row. A client contract that dedicates named staff removes them from the pool through the constraint register, SET LOCALLY.
• Structural. A unit with no bid portal collects preferences by survey; step 5 is varied with a review date. A partner-held scheduling seat that builds on its own engine publishes through the function's channel under a variant row until the catalogue and the rule set are shared.
• Transitional. A unit migrating from a predecessor organization that exports and re-keys schedules by hand carries a row with an expiry at the platform cut-over and an automation effect of blocks against the publication candidate.

L3 register

A localizing team writes these job aids against the generic L2; names only, the content is the function's.

Job aid	Anchored to	Form
The build calendar: offsets from the requirement release to publication	steps 1 to 12	work instruction
The requirement reconciliation query and the discrepancy band	step 1	work instruction
The availability refresh checklist and its sources	step 2	work instruction
The catalogue adequacy test	step 3	work instruction; method on Shift Design
The rule register layout and the period confirmation	step 4	work instruction; see Labor Law and Scheduling Compliance
The window procedure and the allocation mechanism in force	steps 5 and 7	playbook; method on Schedule Bidding and Preference Based Scheduling
The three report templates and their bands	steps 8 to 10	work instruction
The approval pack and the publication record	steps 11 and 12	work instruction
The exception window: triage categories and the handover to maintenance	step 13	playbook
The rebuild path when a check fails after the calendar's last offset	steps 8 to 12	runbook

Automation candidates

Flagged at L2 per the method on Process Decomposition (L0–L3); released per class of action on a published catch rate per Human Gates and Number Grades, never on a maturity label.

1. The compliance check (201-10a): a rule set evaluated as hard constraints; the first candidate because every known error is enumerable and its catch rate is the easiest to publish.
2. The coverage report (201-08a): computed, not decided. It ranks after the compliance check because its arithmetic runs against a requirement that itself carries a grade, so its catch rate is published net of forecast error rather than against a fixed rule.
3. The requirement reconciliation (201-01a), the availability refresh (201-02a and 02b) and the catalogue comparison (201-03a): deterministic queries and comparisons against systems of record. They rank after the coverage report because they read several systems, and a mismatch between two systems is an error no single rule can see, so the catch rate needs a reconciliation sample before it can be published.
4. The fairness report (201-09a): computed against the cohort definitions the function sets. It ranks after the queries because the cohorts change with the function's design, and the catch rate is republished at every change.
5. Publication and notification (201-12a): mechanical once approved; the timestamp it writes is the record a regulator reads. It ranks after the fairness report because its errors, though few, are visible outside the function, so the catch rate is published from a longer observation window before release.
6. The window procedure (201-05a): open, notify, close. It ranks after publication because a publication error is seen by every reader of the schedule the same day, while a window error (a missed notification, a late close) surfaces only through complaints, which makes its catch rate the slower of the two to establish.
7. The generate-and-check loop (201-06a, 07a): an agent may iterate the engine against the three reports and present the best candidate; the scheduler reviews the reports, not the schedule. It ranks last because its errors are judged against a benchmark schedule the function must first build and publish.

The approval to publish (201-11a) is never a candidate: it starts a notice period and binds a change premium, which makes it a signature. The hardship exception (201-13b) is never a candidate: it is a judgement about a person. The review literature on staff scheduling classifies the methods the loop in candidate 7 would iterate over; the choice among them, and the benchmark the loop is judged against, is the function's, not the agent's.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a function that publishes on a calendar, with a notice period, a timestamp and a version 1 of record, is at Level 2; one that has released the compliance check, the coverage report and the fairness report on published catch rates, and generates with preferences as weighted constraints, is at Level 3; one whose generate-and-check loop is agent-run and whose scheduler reviews reports rather than schedules is at Level 4, the multi-objective practice Employee Scheduling describes.

See Also

• Process Standardization — the hub and the inventory this card belongs to
• Employee Scheduling — the five-step sequence this card decomposes
• Schedule Generation and Schedule Optimization — the method inside step 6
• Schedule Bidding and Preference Based Scheduling — the allocation mechanisms inside steps 5 and 7
• Shift Design — the catalogue step 3 tests
• Labor Law and Scheduling Compliance — the statutory parameters of steps 10 and 12
• Schedule Maintenance (generic process) — where the schedule goes at window close
• Standard and Variant in Process Documentation — how the variants above are recorded
• Wiki:Packs/Process Decomposition — the pack that localizes this card (CP-OPS-001)