# Reporting a dispatcher issue

If something looks wrong — an order assigned to the "wrong" driver, delayed, or stuck unassigned — the fastest way to get it resolved is to report it with the right information the first time.

Screenshots alone, especially of unrelated screens, rarely help. Specific, matched details do.

## What to include

| Detail | Why it matters |
|---|---|
| **Request ID** | Identifies the exact dispatcher run involved. Shown in the execution summary on the plan's detail view in the Scheduler, and looks like `req_1785152470621_6v3uobxk86e`. This is the single most useful thing you can provide — more so than the store, because it points to one exact run |
| **Order ID / ticket number** | Without it, the affected order can't be traced |
| **Store** | Which store's run is affected |
| **Date and approximate time** | Narrows down which cycle to examine |
| **What you expected** | For example: "should have gone to an idle driver at the store", "should have stayed with the original driver" |
| **What actually happened** | For example: "stayed unassigned for 12 minutes", "was reassigned to a different driver", "went to a carrier instead of our own fleet" |
| **One-off or recurring?** | A single order and a pattern across many orders point to very different causes |
| **Was it a Priority Customer (Platinum) order?** | Helps rule the optional Platinum layer in or out |
| **Any recent configuration changes** | A zone, store or carrier setting changed shortly beforehand helps separate cause from coincidence |

## What evidence actually helps

- A screenshot of the **specific order's detail screen**, showing timestamps and current assignment — not an unrelated dashboard or list view.
- If several orders are affected, list **all** the order IDs rather than describing them generally ("several orders around lunchtime").
- If you think a particular driver or carrier was skipped, name them, rather than saying "it didn't pick the right one".

## What to avoid

- Reporting without the Request ID or the order ID. These are the two things nothing else can substitute for.
- General statements such as "the algorithm is broken" or "it's not working today", without a specific order, store and time.
- Attaching many unrelated screenshots instead of the one screen relevant to the order.

## Before you report

Two behaviours are frequently mistaken for faults. Checking them first can save a round trip:

- A store where nothing has changed is **skipped**, not processed — see [The assignment cycle, step by step](/books/console-yF7/page/the-assignment-cycle-step-by-step).
- Editing a plan's Active field does **not** start or stop the cycle. Use the **Activate** and **Pause** actions — see [Scheduling plans: how the automatic cycle works](/books/console-yF7/page/scheduling-plans-how-the-automatic-cycle-works).

> The clearer and more specific the report, the faster it can be matched against the actual run that produced the behaviour you're describing.