> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Parallel Dispatch (Optimistic Locking)

> Run Ticket Dispatch in parallel without double-bookings — drop the sequential safety knob without losing the safety net

When a burst of new tickets arrives, Neo Agent normally dispatches them in parallel — much faster than processing one at a time. But running dispatch workflows in parallel has historically had a subtle risk: two tickets that arrive seconds apart can both ask the AI "who's free right now?", get the same answer, and end up double-booked on the same technician's calendar.

**Parallel Dispatch** is the safety net that solves that race. It lets your dispatch workflows run fully in parallel for high throughput, while making sure each technician's calendar slot can only be claimed by one ticket.

<Info>
  Parallel Dispatch is rolling out to clients in waves. Newly created dispatch workflows pick it up automatically as the rollout reaches your account; existing workflows continue to work unchanged. No action is required from you to enable it.
</Info>

## What it does

When a Ticket Dispatch action runs with scheduling enabled, Parallel Dispatch quietly:

* **Reserves the chosen calendar slot** the moment the AI picks it, so two simultaneous dispatches can't both grab the same time on the same technician.
* **Falls back automatically** to the next best technician if the slot was reserved by a peer dispatch a moment ago — without re-running the AI, so there's no extra latency.
* **Shows peer activity in the AI's context** so it can prefer technicians who aren't already being considered by another in-flight ticket.

You won't see a new setting in the workflow editor. It runs underneath the existing Ticket Dispatch action automatically whenever calendar booking is enabled.

## Why it matters

<CardGroup cols={2}>
  <Card title="No more silent double-bookings" icon="shield-check">
    Concurrent dispatches that pick overlapping slots used to fail quietly — both tickets ended up on the same technician's calendar at the same time. Parallel Dispatch makes that impossible.
  </Card>

  <Card title="Burst-day throughput" icon="bolt">
    A Monday-morning burst of 30 new tickets dispatches in the time it takes to process the slowest single one, not 30 in a row.
  </Card>

  <Card title="No AI re-runs on conflict" icon="circle-pause">
    When the AI's first pick loses the slot race, Neo Agent walks the AI's pre-ranked alternatives instead of calling the AI again. Conflict recovery is essentially free.
  </Card>

  <Card title="Zero workflow changes" icon="hand">
    Existing dispatch workflows benefit automatically once your account is on the new behavior. Your settings, custom instructions, and pool sources continue to work as-is.
  </Card>
</CardGroup>

## When sequential dispatch is still the right choice

Parallel Dispatch replaces most uses of the **Process Entities Sequentially** workflow setting, but not all of them. Keep it on when:

<AccordionGroup>
  <Accordion title="Your dispatch workflow doesn't book calendar slots">
    Sequential mode is still the right answer for dispatch workflows that only assign a technician without adding a scheduled entry. There's no slot to reserve in that case, so the parallelization safety net doesn't apply.
  </Accordion>

  <Accordion title="You want predictable, one-at-a-time processing for non-dispatch actions">
    Sequential mode also covers actions like Find Ticket to Merge With and Trigger Another Workflow, where order matters across tickets. Parallel Dispatch only addresses the calendar-collision case.
  </Accordion>

  <Accordion title="Your volume is low and you don't see throughput pressure">
    For workflows that fire a handful of times per day, sequential mode's simpler semantics are still a reasonable choice. There's no harm in leaving it on — Parallel Dispatch will treat sequential workflows as a no-op (the one-at-a-time guarantee already prevents the race).
  </Accordion>
</AccordionGroup>

## Migrating an existing sequential dispatch workflow

If you have a dispatch workflow currently running with **Process Entities Sequentially** enabled, you can safely turn it off once Parallel Dispatch is active on your account:

<Steps>
  <Step title="Confirm the workflow books calendar slots">
    Open the workflow's Ticket Dispatch action settings. Under **Scheduling options**, verify that calendar booking is enabled. If it isn't, leave sequential mode on — Parallel Dispatch only protects scheduled dispatches.
  </Step>

  <Step title="Turn off Process Entities Sequentially">
    In the workflow's general settings, uncheck **Process Entities Sequentially**.
  </Step>

  <Step title="Save and let it run on real traffic">
    Save the workflow. The next burst of tickets will dispatch in parallel. Calendar collisions remain impossible — the safety net catches what serialization used to prevent.
  </Step>

  <Step title="Check Event History after the first busy day">
    Open the workflow's Event History after a high-volume window. You should see dispatches finishing concurrently rather than queuing one-by-one. If a dispatch's reasoning mentions falling back to a different technician, that's Parallel Dispatch's conflict recovery working as designed.
  </Step>
</Steps>

<Tip>
  You don't have to migrate every workflow at once. Start with your highest-volume dispatch workflows — those are where Parallel Dispatch produces the biggest throughput win.
</Tip>

## Expected throughput improvement

The improvement depends on how many tickets the workflow processes in a typical burst:

| Workflow shape          | Before (sequential)        | After (parallel)                                 |
| ----------------------- | -------------------------- | ------------------------------------------------ |
| 5-ticket burst          | \~5–10 minutes serially    | All 5 finish within the slowest single dispatch  |
| 30-ticket burst         | Up to \~2.5 hours serially | All 30 finish within the slowest single dispatch |
| Steady-state low volume | No meaningful change       | No meaningful change                             |

For workflows that handle scheduled dispatches with frequent multi-ticket bursts (after-hours backlogs, Monday-morning queues, post-outage cleanup), the practical effect is "the queue is gone."

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I need to enable anything in the workflow editor?">
    No. Parallel Dispatch runs underneath the existing Ticket Dispatch action automatically whenever the action has calendar booking enabled. There's no checkbox to toggle.
  </Accordion>

  <Accordion title="What happens if every alternative technician is also busy?">
    If the AI's primary pick and every ranked alternative all have their slots claimed by concurrent peers, the dispatch retries from scratch — Neo Agent re-fetches the now-updated calendars and the AI picks again with fresh context. This is rare in practice; it requires four-plus dispatches racing on the same window for the same technicians at the same time.
  </Accordion>

  <Accordion title="Will it change the AI's technician selection?">
    The AI's primary recommendation is unchanged. Parallel Dispatch only kicks in if that primary pick's slot is claimed by another in-flight dispatch — and it walks the AI's own ranked alternatives, not a different algorithm.
  </Accordion>

  <Accordion title="Does it affect Round Robin dispatch?">
    Yes — Round Robin dispatch also benefits when scheduling is enabled. The same slot-claiming safety net applies whether the chosen technician came from the AI or from Round Robin rotation.
  </Accordion>

  <Accordion title="Can I see how often conflicts happen?">
    Conflict and fallback events are tracked in observability dashboards on the Neo Agent side. If you want a per-workflow report, reach out to support — we can pull the rate for any workflow you're piloting the migration on.
  </Accordion>
</AccordionGroup>