Pharmacy Fulfilment Automation | Warehouse Execution for Pharmacies

Pharmacy Flow already holds the record: orders, lots, locations, receiving, QA and putaway, pack-verify, shipping. The execution layer is what turns that record into the next physical action. It models three things, a resource that does work, a task that is one unit of work, and a wave that releases tasks together, and it treats a person and a machine as the same kind of resource. This page describes exactly what is built today and what is still on the roadmap, because a fulfilment buyer deserves that distinction.

Three primitives: resource, task, wave

Resource: Anything that executes work. Kind is one of human, AMR, AGV, sorter, AS/RS or put-wall. A resource has capabilities (which task types it may take), a zone, a live status of idle, busy or offline, and, for machines, an API key issued when the resource is registered.
Task: The atomic unit of physical work. Type is one of receive, putaway, move, pick, replenish, count, sort or pack. A task carries from and to locations, the item reference and quantity, an acceptance criterion (what done requires: a scan, a cold pack), and handling flags for cold chain, controlled, hazmat and temperature control. Lifecycle: pending, ready, assigned, in progress, then done or exception.
Wave: A batch of tasks released together with a strategy and a progress rollup. A wave completes itself when its last task closes.

All three are tenant-scoped tables under row-level security, the same as every other record in the platform.

From orders to a released wave

1
Plan
The planner takes the most recent open orders (up to sixty per wave) and emits a pick, pack and sort task chain for each. It stamps cold-chain and controlled flags from the product family, sends cold picks to the Cold zone and controlled picks to the Vault zone, and gives controlled picks a higher priority.
2
Release
Releasing a wave flips its pending tasks to ready and timestamps the release. Nothing is dispatched until it is ready.
3
Dispatch
Auto-dispatch assigns every ready task, in priority order, to a resource whose capabilities include that task type, round-robin across the matching fleet. A manual assign covers targeted work.
4
Advance
Start, complete or flag an exception. Starting marks the resource busy; completing or excepting frees it once it holds no other in-progress task. Completing the last task completes the wave.

Fulfilment Control Tower showing the task board by status, the resource fleet and wave progress — The Control Tower: tasks by status, the fleet of people and machines, and wave progress on one board.

Dispatch to people and machines from one model

The dispatcher does not know or care whether a resource is a technician or a robot. It filters resources by capability, walks them in turn, and writes the assignment with the resource's id, kind and name. A human sees the assignment on the Control Tower and works it from the screen or the scanner PWA. A machine finds out the same way it finds out about everything: by asking the API. That is what makes adding a robot an operational change rather than a software project. Register it as a resource with the capabilities it has, give the vendor's adapter its key, and it starts taking work from the same queue.

Shipping list with parcels, carrier, service, cold-chain flag, status and scans

Outbound is part of the same record

When a task chain ends at the ship station, the parcel record that the pack station created carries carrier, service, packout and the cold-chain flag; the ship action adds it to the facility's open SSCC carton, writes the shipment and moves the order to Shipped. Carrier scans arrive by webhook and are stored once each, keyed on the carrier's event id. Delivery cascades to the order and to the partner's order.delivered webhook, but not while a cold-chain QA hold is open on the parcel.

The machine task API

A machine authenticates with its resource key in an x-resource-key header (or as a bearer token) and calls GET /api/fulfillment/tasks. The response is either the task it already holds (assigned or in progress, highest priority first), or the next ready task in its tenant whose type matches one of its capabilities, claimed with a conditional update so two machines cannot take the same task. If it loses the race it is told to retry. The task payload is deliberately plain:

The task object a machine receives. Same fields the Control Tower shows a human.
Field	Meaning
`taskId`, `type`, `status`, `priority`	Identity and ordering.
`item.ref`, `item.name`, `item.qty`	What to move and how much; the order number is the reference for pick, pack and sort.
`from`, `to`, `zone`	Locations, for example Cold-07 to Pack-IN.
`handling`	`coldChain`, `controlled`, `hazmat`, `tempControlled` booleans the adapter must respect.
`acceptance`	What done requires: scan unit, scan plus cold pack, insulated plus gel packs, SLAM label.
`report`	The URL to POST progress to: `/api/fulfillment/tasks/{id}`.

Each poll updates the resource's last-seen time and marks it busy. Reporting completion frees it. The audit trail is identical for both kinds of worker: the task keeps its resource, assignee and timestamps, and the wave's rollup counts them the same.

The scan-gated stations

Tasks end at stations, and stations are strict. Fill claims the earliest-BUD available lot of the order's exact variant, mints the serial and prints the vial label. Pack creates the parcel and prints the 4×6 label, choosing a cold-chain packout and expedited service for temperature-sensitive families. Verify checks that the scanned serial belongs to the scanned order, is packed, is not recalled and is not past its BUD, and puts the order On Hold with the reason if any check fails. Ship refuses an unverified order, and the database refuses it again. Every station writes an EPCIS-style event. These stations are described in more depth on the compounding software page and in the serialisation guide.

Pack verify station with scanned order, scanned serial and the pass or hold result — Verify: the four checks run server-side on every scan. A fail holds the order and records why.

Plan a wave on your own orders

Twenty minutes: we load a handful of your orders, plan and release a wave, dispatch to a human and a simulated robot, and walk a unit through Fill, Pack, Verify and Ship.

Request a demo See the Control Tower

Handling flags and chain of custody

Every task carries its handling flags, every task records who or what touched it and when, and every station writes an event with a read point. That is the chain-of-custody backbone. Today the flags are stamped by the planner, shown to humans and delivered to machines in the task payload; dispatch matches on task type, and honouring the flags is the responsibility of the adapter or the operator. Constraint-aware dispatch (a controlled pick that can only be assigned to a vault-authorised resource, a cold pack only to a cold-capable station) is the next hardening step, listed below. We say this plainly because a buyer who is told the constraint is already enforced, and later finds it is not, has been misled about the one thing that matters most.

✓Cold-chain and controlled flags set from the product family at planning time
✓Controlled picks routed to the Vault zone and prioritised ahead of standard picks
✓Resource, assignee, assigned, started and completed timestamps on every task
✓EPCIS-style commissioning, packing, inspecting and shipping events with serial and SSCC
✓Parcel temperature readings against 2–8 °C, with an excursion opening a QA hold that blocks delivery

Shipped today, on the roadmap

From the WES architecture document. Dispatch today is capability plus round-robin.
Capability	Shipped	Roadmap
Resources, tasks, waves with RLS	✓
Wave planner (pick → pack → sort per order)	✓	Batch, zone and cluster strategies; pick-path sequencing
Capability-matched auto-dispatch, manual assign	✓	Constraint-aware dispatch on handling flags
Machine pull and report API with per-resource keys	✓	Row-locked claiming for large robot fleets
Live Control Tower: board, fleet, wave detail	✓
Receiving, QA release and rule-suggested putaway (WMS)	✓	Receiving as WES task chains; ASN ingestion; dock scheduling
Replenishment and cycle-count task generation	—	Pick-face min/max replenishment, continuous counting, slotting
Goods-to-person and AS/RS integration	—	Adapters per vendor speaking the task API
Automated sortation and SLAM	—	Sorter dispatch, carton selection, manifest close-out

If you are evaluating vendors, the buyer's guide and the comparison page put this table next to alternatives, and the automation guide explains why the order (orchestration first, machines second) matters.

Who this is for

Mail-order and telehealth fulfilment

Volume that arrives by API and leaves by carrier, where the constraint is the floor. See mail-order and the order API.

GLP-1 and other cold-chain programmes

Every pick and pack flagged cold-chain, temperature readings on the parcel, QA holds on excursions. See GLP-1 fulfilment.

503B and multi-site networks

Office-stock volume across facilities with per-site resources and routing. See 503B and local manufacturing.

Frequently asked questions

Do we need robots to get value from this?+

No. The planner, dispatcher and Control Tower run entirely on human resources. A technician's assignment appears on the board and on the scanner. Machines are added later as resources with API keys and take work from the same queue.

How does a robot receive work?+

It calls GET /api/fulfillment/tasks with its resource key. It gets back the task it already holds, or claims the next ready task matching its capabilities. It reports progress to the report URL in the task.

Can two machines claim the same task?+

No. The claim is a conditional update that only succeeds if the task is still ready. The loser is told to retry. For very large fleets, a row-locked claiming procedure is on the roadmap.

Are controlled or cold-chain tasks prevented from going to the wrong resource today?+

Not by the dispatcher. The flags are on every task and in the machine payload, and controlled picks are routed to the Vault zone with higher priority, but dispatch matches on task type. Constraint-aware dispatch is the next planned hardening step.

What is the difference between this and the WMS?+

The WMS is the record: lots, locations, transactions, receiving, QA, putaway, parcels. The WES is the execution layer that turns open orders into tasks, dispatches them and tracks them to done. Both are in the same application and database.

Which automation vendors are supported?+

None are integrated out of the box today. The task API is vendor-neutral; an adapter per vendor is the planned integration pattern. If you have a specific fleet in mind, tell us during the demo.

Is the WES multi-tenant?+

The resource, task and wave tables are tenant-scoped with row-level security like the rest of the platform, and the machine API scopes task claims to the resource's tenant.

Keep reading

WMS & Control Tower →

The record underneath and the board on top.

Telehealth order API →

How orders arrive before they become tasks.

Automation guide →

Orchestration first, machines second: the sequence that works.

GLP-1 fulfilment →

Cold-chain flags, temperature readings and QA holds in practice.

Buyer's guide →

What to ask any fulfilment vendor.

Cold-chain shipping →

Packout, readings and excursion handling.

Fulfilment automation that starts with the task, not the robot