Request triggers in the workflow editor
IT turns on the calling app. Drivers start getting half-empty jobs with no destination. Operators go back to the radio. The marketplace did not fail at matching. It failed at naming how the plant already asks for material.
What the workflow editor actually configures
The workflow editor is the setup surface for how an internal logistics request begins. You create each trigger type one by one: a physical button at a production station, a barcode scan, a touchscreen choice, or an automated request from MES over a REST API. For every trigger you set the material classes it may request, the priority band, the destination zones it may serve, and which order template it feeds. Milk-run material often opens a multi-stage path into a supermarket prep template, then a tugger delivery template. Forklift material usually opens one direct pallet bring, empty remove, or both. Those templates are described in milk-run orders vs direct forklift orders.
This step is pure setup. It does not invent new processes. It captures how the plant already expresses needs so the marketplace can understand them later. Plants that skip the mapping leave drivers with incomplete or mismatched calls. How the finished request becomes a claimable work order is under how a floor request becomes a work order.
Driver groups and acceptance rules in AOS
Once request templates exist, AOS (commonly known as FGS) turns them into calls drivers can accept, the same job class as a forklift guidance system. In the same configuration layer you create driver groups by hall, shift, and vehicle class: supermarket prep, tugger milk-run delivery, forklift line feed, dock. An open work order is broadcast to everyone in the assigned group. The first eligible driver who accepts owns the job. Location is recorded at acceptance when movers are tracked. Location does not currently decide who may see the offer.
Acceptance logic sits next to the groups. Timeouts, re-call intervals, and the fallback when nobody accepts are parameters you enter here. The system records acceptance time, location, and identity after a driver in the group claims the call. How group broadcast differs from nearest-truck myths is under group broadcast vs nearest-truck myths. How to size those groups is under how to size and split driver groups.
Floor devices, MES mapping, and a dry-run
Configuration is incomplete until devices and external systems link to the templates. Each button, scanner, or terminal maps to exactly one request type. When MES is the source, incoming fields translate into material ID, quantity, source, and destination so operators never type free text at call time. After save, supervisors fire test requests from the same buttons and scanners and watch which drivers receive the call. If a group is too broad or a priority is wrong, the change goes back into the editor before the live marketplace opens.
That catalogue of templates is what keeps every accepted job complete from the first second. Without it, live matching forces drivers to fill gaps that should never have existed. twinzo's ordering and calling setup sits under material order automation, with the wider logistics job on internal logistics optimization and capability depth on the features overview.
How teams decide setup is done
1. List every way the floor already asks for material - Button, scan, screen, MES, radio. Radio leftovers become the migration list.
2. Map one high-traffic loop end to end - Prefer one supermarket-to-tugger milk-run path and one station-to-forklift path before mixing them.
3. Refuse live go-live until test calls look complete - Missing destination or material class means more editor work.
4. Name the owner who may change templates after go-live - Usually logistics with IT support, not a one-time project leave-behind.
How a rollout is priced is on pricing. The trail those configured calls leave is under the call that starts the record.
Get in touch if you want to walk how your plant's existing buttons and MES fields should map before the first live call goes out.