You are here:
Fine-Tune a Workforce Scheduling Policy
In scheduling policies, you set weights to service objectives. These weights represent the importance of each objective when the engine generates an optimal schedule. You can fine-tune the weights through an iterative tuning process to set weight values in your scheduling policy that closely align with your business KPIs.
Required Editions
| Available in: Lightning Experience |
| Available in: Enterprise and Unlimited Editions |
| User Permissions Needed | |
|---|---|
| To create, edit, or clone scheduling policies: | Workforce Scheduling Admin |
| To run global optimization to test a policy: | Workforce Scheduling Dispatcher |
Tune a scheduling policy against production-like data so you know a change improves the schedule before you apply it broadly. These steps are a starting point. They outline a general framework for fine-tuning your scheduling policy weights through an iterative process: simulate, collect data, analyze, and refine. You can modify and expand these steps to meet your specific requirements.
Prepare a Sandbox
- Collect production-like data in a sandbox to use for simulation testing. Preferably perform a refresh from production into a full sandbox.
- Confirm Workforce Scheduling is enabled and the policy you want to tune is present.
Establish a Baseline
Run the current policy first so you have something to compare against.
- Select two or three service territories to perform simulation testing on. Preferably choose diverse territories so you can test on a dataset that is representative of all your Salesforce data.
-
Select a future date range start time to perform testing, depending on how long you
expect testing to take. It’s better to select a date range in the future so the passing of
the current time doesn’t affect the optimization window. For example, if today is January
1, 2026, and you expect the tuning exercise to take 3 days, select a date range for
optimization to start no later than January 5, 2026. This way the current date doesn’t
overlap with your optimization date range and interfere with results.
Note For a more realistic test dataset, update the dates within the dataset based on the amount of test data available for the selected date range. - The optimization horizon date range must match what you intend to configure in production. For example, if you are testing the global optimization that has a horizon of 3 days, the optimization horizon for the testing is January 5, 2026 to January 7, 2026.
- Create a copy of the scheduling policy that you’re testing for fine-tuning and rename it to show that it’s the baseline scheduling policy. For example, ABC_Baseline.
- Unschedule all the appointments in the testing data domain so that you start the tests, even the baseline, from a clear Gantt for accurate comparisons.
- Run global optimization with the current policy.
- Record the metrics: runtime, appointments scheduled, resource utilization, average travel time per appointment, overtime utilization, and any other KPI that matters to your business. Look at the routes and take screenshots of the Gantt. If possible, save the schedule by exporting the service appointment schedule times and Assigned Resource records for analysis.
- Repeat the runs using various scheduling policies until you achieve the optimal results for your business.
Test the Tuned Policy
- Copy the scheduling policy and rename it to show the test number and what you are planning to change in this policy.
- Change one variable at a time. Adjust one objective’s weight, add one work rule, or swap one objective. We recommend you change only one variable at a time, and test how it affects the results. Otherwise, it can be difficult to determine which change impacted the results. Keep in mind that weights are relative to the other objectives in the same policy — a higher weight tells the scheduling engine to prioritize that objective more. What matters is the ratio, not the number.
- Run global optimization with the copy on the same territories and date range.
- Compare the KPIs to your baseline. Look for improvement in the metric you targeted without regression in the others.
- Iterate. Repeat the change-and-measure loop until the KPIs stabilize.
Roll Out to Production
- Apply the tuned policy to one production service territory first. Choose a territory whose behavior you understand well.
- Monitor the KPIs for two or three days of scheduling activity.
- Compare production results to the sandbox baseline and to that territory’s prior performance.
- Extend the policy to remaining territories after the first territory looks healthy.
Small weight changes often produce visible schedule shifts because service objectives interact. Expect a few iterations before schedule quality stabilizes. Save each run’s output before you start the next iteration so you can trace which change moved which KPI. If a change makes things worse, revert to the prior version of the policy and try a smaller change. Large weight swings can overcorrect and hide a smaller adjustment that would have worked better.
When you’re happy with the results, you can use your newly tuned scheduling policy in your production environment. We recommend you test the new policy with a few service territories first and get feedback from users before you roll it out to all service territories.
