The assignment cycle, step by step

Every time the dispatcher runs, it processes each store independently, following five steps in order.

The five steps

# Step What happens
1 Fetch data Pulls current orders, available drivers, and store and zone configuration. This is also when any order still sitting with a Third-Party carrier from a previous cycle gets re-examined — see Re-checking orders already with a carrier.
2 Cache check If nothing has changed since the last run, the store is skipped rather than re-processed, to save time and resources.
3 Assign orders The core decision-making step, covered in The three assignment mechanisms. This is where Third-Party, your own fleet and — optionally — Priority Customers logic all come together.
4 Post-process Results are categorised (new assignments, still-pending orders, orders sent to Third-Party, and so on), orders that can be grouped onto the same driver are identified, and anything still unassigned gets one final relaxed attempt — see Last-Option: the final safety net — before being marked Pending or Critical.
5 Save and notify Final assignments are saved, drivers are notified by push notification, and any relevant alarms are processed.

Step 2 is the reason a run can complete almost instantly for a quiet store. A skipped store is not an error, and nothing is lost — the next cycle picks it up the moment anything changes.

What "independently, per store" means in practice

Each store is solved on its own. A driver shortage at one store never pulls drivers from another, and a store whose data hasn't changed is skipped without affecting the rest. This is also why a report of a dispatcher problem should always name the store — see Reporting a dispatcher issue.

Where the deeper detail lives

Steps 1 and 3 carry almost all of the decision-making, and each has its own page:


Created 2026-09-17 16:28:18 UTC by Fran Sanchis
Updated 2026-09-18 07:48:13 UTC by Fran Sanchis