Guidelines for Using Workforce Scheduling Commit Mode

Various conflicts can occur in the schedule during an optimization run. For example, while optimization is running, a dispatcher pins a service appointment, a customer cancels an appointment at the last minute, or an emergency service appointment is created and scheduled automatically. These actions can result in discrepancies between the schedule at the start of optimization and the schedule upon completion. If a scheduling change during optimization creates scheduling conflicts, you can commit the optimization recommendations despite the conflicts or roll back to the original schedule without making any changes.

Always Commit

If a user tries to make a potentially conflicting change to the schedule while optimization is in progress, a message is shown to warn the user that their change can conflict with the optimization results, but lets them opt to save the change. If the conflicting change is made by automation or a user outside of the Operations Console, no message is shown.

Rollback

If a potentially conflicting change is made to the schedule for the dates being optimized—with a buffer day before and after—don’t complete the optimization. This choice is a conservative scheduling option that helps you avoid possible conflicts. For example, if you begin a scheduled job to optimize from April 2 to April 5, changes made to the April 1 to April 6 schedule cause the optimization to be rolled back. Changes include creating and deleting resource absences and service appointments, any resource absence updates, and updates to the service appointment assigned resource, Scheduled Start or Scheduled End.

Note In rare cases, a service appointment can incorrectly have two assigned resources even if the scheduling policy is set to Rollback. This can occur if a dispatcher manually assigns a service appointment on the Gantt at the exact same time an optimization request is about to commit its results. The rollback check (which looks for Gantt changes) can finish right before the manual drag-and-drop action completes. Because the check detects no change at that moment, the rollback isn’t triggered, and the optimization results are committed, resulting in the duplicate assignment.

Each optimization type has its own org-wide default Commit Mode:

• Global Optimization defaults to Always Commit, because global runs are typically overnight when concurrent changes are rare and partial improvements are usually preferable to no change.
• In-Day Optimization defaults to Rollback, because in-day runs happen during the working day when concurrent changes are likely, and rolling back protects the schedule from conflicts.
• Resource Schedule Optimization (RSO) defaults to Rollback, because RSO covers a single resource’s day and rolling back on any concurrent change keeps the resource’s schedule consistent.

You select the Commit Mode for each optimization type from Setup, under Scheduling and Optimization.

Here are examples of potentially conflicting schedule changes and what happens depending on the selected Commit Mode.