AI Job Dispatcher

Executive Summary

Dispatch is a job that looks like judgement and is mostly lookup. Who has an open job, who is free this afternoon, who is closest to it: three questions a person answers slowly from three different screens, and an agent answers instantly from the same data.

This is a Power Automate and AI Builder agent that runs that loop end to end: it discovers unassigned jobs, checks which engineers are genuinely available, ranks them by distance using the GPS position captured by the field check-in app, and assigns the nearest one. Anything it cannot confidently match goes to a dispatcher queue rather than being guessed at.

The Problem

Assignment was being made against the rota, a document describing where engineers were supposed to be. By mid-morning that document is fiction. Jobs overrun, jobs get cancelled, engineers end up on the other side of the region from where the plan said they would be.

The result is the familiar field-service tax: an engineer driving past an open job to reach the one they were assigned, because the assignment was made before anyone knew where they were. The information needed to avoid that already existed, the check-in app had been capturing real positions for months. Nothing was reading it.

The Solution

The agent runs as a four-stage pipeline over Dataverse. Each stage is separately observable, which matters more than it sounds: when a dispatch decision looks wrong, you need to be able to say which stage made it.

• Discover. Query the job queue for work that is open and unassigned. No human has to notice a job is sitting there.
• Check availability. Test each engineer against shift and existing commitments. Being nearest is irrelevant if you are already on a job.
• Rank by distance. Compare the job location against the engineer's most recent check-in position, live GPS from the field app, not a home depot address.
• Assign. Write the assignment back to Dataverse and notify the engineer. Where no candidate clears the availability and distance checks, the job routes to the dispatcher queue with the reason attached.

Architecture

Everything the agent needs is already in Dataverse: the job queue, the engineer roster, shift availability, and the stream of check-in positions coming out of the field app. The flow reads across all four, makes one decision, and writes one thing back.

The design choice worth defending is the fallback. It would have been easy to always assign somebody, pick the least-bad candidate and move on. That produces a system nobody trusts, because the bad assignments are indistinguishable from the good ones. Routing an unmatched job to a human, with the reason it could not be matched, keeps the automatic assignments meaningful.

Engineering Highlights

• Assignment is made on position at the time of dispatch, sourced from the check-in app rather than from a planning document that goes stale before lunch.
• Availability is checked before distance, not after. Ranking a full engineer as nearest and then discarding them wastes the only interesting comparison in the pipeline.
• The pipeline is idempotent per job, a re-run over an already-assigned job is a no-op, so the flow is safe to retry after a transient failure.
• Every decision carries its reason. When someone asks why a particular engineer got a particular job, the record answers it without anyone reconstructing the run.
• No-match is a first-class outcome with its own queue, rather than a silently forced assignment.

Technologies

Results & Impact

Jobs now get assigned to whoever is genuinely nearest and free, without a person sitting between the queue and the engineer. The dispatcher role shifts from doing the routine assignments to handling the exceptions the agent deliberately declines to guess at, which is the right division of labour between the two.

It also demonstrates something I keep finding on the Power Platform: the highest-value automation is usually not new data collection, it is connecting data you are already collecting to a decision that is still being made by hand.