What it does

Three records control what Resource Scheduling Optimization actually does. A scope says which resources, requirements, bookings and time range are in play. A goal says what "good" means, as a set of constraints plus ranked objectives. An optimisation schedule pairs one scope with one goal and runs it on a timer.

Key facts

• A goal has an Engine Effort Level, a Travel Time Calculation method, a list of constraints and an ordered list of objectives. Higher effort considers more combinations and takes longer.
• Constraints are hard restrictions: schedule within working hours, meets required characteristics, meets required roles, scheduling windows, meets resource preferences, matches territories, matches resource type. Scheduling lock options is deprecated.
• Objectives are ranked and order changes the answer: maximise total working hours, minimise total travel time, high priority requirements, maximise preferred resources, best matching characteristic level, schedule as soon as possible. Locked bookings is deprecated.
• Minimize total travel time cannot be the first objective. Typical starting order is maximise working hours, then minimise travel, then skill matching.
• Historical traffic as a travel time calculation supports up to 500 requirements per optimisation scope and is intended for off-hours runs.
• Where a requirement's date window conflicts with promised times, RSO gives precedence to Time From Promised / Time To Promised.
• Removing the "schedule within working hours" constraint lets travel fall outside business hours — that is the intended lever, and it surprises people.
• A scope is built from three views (system or personal): a Resource View, a Requirement View and a Booking View. To handle both unscheduled and already-scheduled work you must select both a requirement view and a booking view.
• The scope's time window is Range Reference (job current time, or beginning of the job's current day), Range Offset and Range Duration (days). Anything outside the resulting window is not created or updated.
• Optimisation schedules have a Timer and a Timer Mode of either Fixed (every interval) or After Job Completion (interval after the previous run finishes), plus Valid From/To and a filter tab for restricting which days it fires.
• Schedule statuses are Unpublished, Publishing, Published, Out of Sync, Under Maintenance and Failed. Changes put a schedule Out of Sync and it must be republished.
• Every run creates a scheduling optimisation request record showing which resources were optimised, which weren't and why, and travel versus working hours.

When to use / skip

If you've bought RSO, you need all three records — there's no "just run it" mode beyond single-resource optimisation. The judgement call is how many goals and scopes to build. Start with one scope and one goal, prove the output is sane, then split only where the business genuinely differs: night shift versus day shift, an emergency scope that runs every thirty minutes against a small high-priority view, a simulation scope for capacity planning. Resist the urge to build a scope per territory on day one; a dozen half-tuned scopes is much harder to debug than one that's slightly too broad. Multiple goals are worth it mainly when emergency work needs different objective ordering from routine work.

Configuration decisions

• Objective ordering, which is where the client's operating model actually gets encoded. "Fill the day" and "minimise driving" produce visibly different schedules and someone senior has to choose.
• Which constraints are hard. Every constraint you add narrows the solution space and increases the chance of unscheduled work — dropping territory matching, for example, is a real business decision.
• Engine effort level against run duration, tuned once you know how long a real scope takes.
• Scope partitioning: temporal (shifts), geographical (territories, cities) or logical (support levels, incident types) — and whether the scope views are system views that everyone can see and break, or locked-down ones.
• Range reference, offset and duration: what "tomorrow" means to this client, and whether today's remaining work is in or out.
• Timer mode and cadence: nightly fixed run, intraday every thirty minutes, or after-completion chaining, plus the day filter so it doesn't fire on weekends.

Gotchas

• Selecting only a requirement view means RSO adds new bookings but never reshuffles existing ones. Most "RSO isn't optimising" reports come down to a missing booking view.
• Personal views used in scopes disappear when their owner leaves or unshares them, and the schedule fails quietly on the next run.
• Editing a scope or goal leaves attached schedules Out of Sync. They stop producing results until someone republishes, and nothing shouts about it.
• Objective order is not a preference list the engine balances — a lower-ranked objective only breaks ties left by higher ones. Clients expect weighting and get precedence.
• Historical traffic looks like a free accuracy win until a scope crosses 500 requirements.
• Runs that appear stuck usually need the schedule reset, and occasionally all schedules reset and republished. Doing this in the middle of the working day rewrites live bookings.
• Optimisation request records are purged after two weeks by the built-in cleanup jobs, so evidence for "why did it do that on the 3rd" ages out fast.

Consultant notes

• Run the same scope with two goals and put the two schedule boards side by side in a workshop. Objective ordering is impossible to explain in the abstract and obvious in a picture.
• Demo the optimisation request record early. Dispatchers trust RSO far more once they can see why a resource was excluded.
• Push back on a scope that covers everyone for two weeks. Narrower scopes run faster, fail more obviously, and are the difference between a five-minute run and one that never finishes.
• Before go-live, run the nightly schedule against production-shaped volumes at the real hour it will fire, and check it finishes before dispatchers arrive.
• Keep one manual, unpublished scope for ad-hoc "what if" runs, so nobody edits the live nightly schedule to answer a question.

---

Worth revisiting when objectives or constraints change in a release wave, or after the first month of live runs when the tuning is real.