Scheduling - Data and Setup Dependencies
Objective. List what Scheduling needs to produce a correct schedule - the signals it consumes, the configuration and integrations it depends on, the other apps it chains with, and exactly what a CSM validates before trusting any coverage or violation reading.
Scheduling is only as right as its inputs. A schedule is a plan against a forecast, so the forecast version is the first dependency; the rules, skills and time zones you set bind every draft that Generate/Optimise produces; and coverage shown is planned, not actual. This reference sets out the data and configuration Scheduling depends on, the apps it chains with, and the CSM validation stops that decide whether a clean-looking draft can be trusted or must be escalated.
See it in the demo
The signals Scheduling depends on
Scheduling turns a staffing requirement into shifts, so it consumes:
- A forecast / staffing requirement - the required demand by interval, normally the output of Capacity Planning. This is the single most important input: coverage is measured as required (from the forecast) versus scheduled (your draft), so the forecast version the draft is bound to governs every reading.
- The workforce roster - who is available, their contracts and hours, and their skills (a draft that covers headcount can still miss a skill the interval needs).
- Availability and constraints - time-off, preferences, approved requests, and employee working-time constraints, which become constraints the draft must honour.
- Shift templates - the shift patterns the planner lays against the requirement.
Each signal has a time basis and a time zone; a schedule read in the wrong time zone shifts every coverage window. Confirm with product which of these are imported versus maintained in Scheduling for a given customer.
Setup, configuration and integrations required
Described at app-logic level (confirm specifics with product):
- Labour rules - rest, overtime, break and working-time rules. These define what counts as a violation; zero violations only ever means zero against the rules configured.
- Skills and skill requirements per interval - so coverage is read by skill, not just by body count.
- Time zones - per site for multi-site teams.
- Shift designer templates - the shift shapes available to the planner.
- Publication and change-ownership controls - who may publish, the notice policy, and how republications are handled.
- Integrations - the link to the forecast source (Capacity Planning), and any HR/roster source for employees, skills and availability. Which integrations and connectors apply, and the supported labour-rule library, must be confirmed with product; the demo shows the model on seeded data.
Getting configuration right is not optional polish - it is the ground truth behind every coverage and violation reading.
Dependencies on other apps
Scheduling sits in the middle of the Workforce Management chain:
- Capacity Planning (upstream) - provides the demand/requirement the schedule is built against. A stale or wrong forecast version makes the schedule confidently wrong. This is the tightest dependency.
- Real-Time Adherence (downstream) - compares actual activity and output against the published schedule. Coverage in Scheduling is planned; whether people adhered and work got done is an RTA question, not a Scheduling one.
- Intraday Management (downstream) - re-forecasts the live day and evaluates corrective action when reality diverges from the published plan.
- Time and Activity / Work Output (context) - attendance, utilisation and completed work give the operational reality the plan is later judged against.
Teaching point: do not answer a delivery question ('did the day go well?') from Scheduling - it only shows the plan.
What a CSM validates before trusting the numbers
Before trusting any coverage or violation reading, a CSM validates four things, in order:
- Forecast version - is the draft bound to the current forecast, not last period's? A clean coverage view on a stale forecast is still wrong.
- Rules and skills - do the configured labour rules and skill requirements match the customer's actual policy? If not, zero violations and full coverage are meaningless.
- Time zone - correct per site, or coverage windows are misread.
- Cleared violations - are the exceptions the draft carries actually cleared before publication?
Escalate to the implementation specialist / product when: the forecast integration or roster/skills import looks incomplete or stale; the customer needs a labour rule that is not in the supported set; time-zone or multi-site handling is unclear; or publication/notice controls do not match the customer's governance. Never assert a compliance or integration capability you have not confirmed - that is a 'confirm with product' answer, not a CSM judgement call.
Interpretation check
A schedule is only as correct as the forecast version it is bound to and the rules, skills and time zone configured behind it. Validate those four before trusting any coverage or violation reading; coverage is planned against the forecast, not a record of actual delivery.
In the field
A multi-site RCM back office across time zones: before any coverage claim, the CSM confirms each site's schedule is on the live Capacity Planning forecast, the rest/overtime rules match local policy, and time zones are set - so a 'fully covered, zero violations' draft is not clean against the wrong policy or the wrong clock.
Practical task
For a seeded demo team, write the input/configuration checklist you would validate before trusting the schedule: the forecast version it is bound to, the labour rules and skills configured, the time zone, and whether violations are cleared. Mark each item 'confirmed in demo' or 'confirm with product', and list two things you would escalate to the implementation specialist.
Self-check
What is the single most important input to a schedule, and why?
The forecast / staffing requirement and its version. Coverage is required (from the forecast) versus scheduled, so a draft bound to a stale forecast looks covered while failing current demand.
A draft shows zero rule violations. What does that actually prove?
Only that it is clean against the rules configured. If the labour rules are not the customer's real policy, zero violations means nothing - validate the configuration first.
Which app answers 'did people actually work the schedule?'
Real-Time Adherence, not Scheduling. Scheduling shows planned coverage; adherence and output are measured downstream in RTA and Work Output.
Name the four CSM validation stops before trusting a schedule.
Forecast version (live, not stale), rules and skills (match the customer's policy), time zone (correct per site), and cleared violations before publication.
A customer asks for a labour rule you have not seen in the product. What do you do?
Treat it as confirm-with-product and escalate to the implementation specialist. Never assert a compliance capability you have not confirmed.
Verified vs demo. Configuration, planner and coverage are demo-shown on seeded data. The forecast/roster integrations, the supported labour-rule library, skill handling, time-zone behaviour and publication controls for a specific customer are confirm-with-product.