Request triggers in the workflow editor
Incomplete request triggers are a setup failure, not a dispatch failure. Live matching only works when every floor ask maps to a complete order template.
What a request trigger is
A request trigger is the configured event that opens a material call-off into AOS (commonly known as FGS). Typical sources are a station button, a barcode or RFID scan, a touchscreen choice, an e-Kanban flip, an Andon-style call-for-parts panel, or an automated message from MES over a REST API.
Industry FGS and e-Kanban stacks make the same demand: the floor signal must become a logistics task with material, quantity, origin, destination, and priority, not only a board color or a free-text shout. The trigger names how the plant already asks. It does not invent a new process. Which source should own a given loop is under when MES should open the job vs when the line button should.
What the workflow editor configures
The workflow editor is the setup surface for those triggers. For each type 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 shapes are under milk-run orders vs direct forklift orders.
This step is pure configuration. Plants that skip it leave drivers with incomplete or mismatched calls once the marketplace opens. How the finished request becomes a claimable work order is under how a floor request becomes a work order. Wiring an e-Kanban flip into that same path is under e-Kanban cards that become claimable work orders.
Driver groups and acceptance rules
Once request templates exist, AOS turns them into calls drivers can accept. 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. When movers are tracked, the system records acceptance time, location, and identity. 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. 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 internal logistics job on internal logistics optimization and capability depth on the features overview.
What complete triggers leave behind
A complete trigger does three equal jobs for the plant. On the shift it opens a claimable work order so drivers stop hunting the next ask on radio. In storage it starts the dispatch trail that lands in the spatially oriented dataset when positions share the hall frame. For later review, those closed calls are what correlation and causality analytics use when the same request gap keeps preceding a wait or empty loop.
That is why setup quality is not only a lean manufacturing go-live checkbox. A smart manufacturing program that ships incomplete fields poisons live logistics, the stored place-and-time record, and pattern work on the same footing. How that trail begins as a call record is under the call that starts the record. Production-side monitoring of the same events sits under production monitoring.
How teams decide setup is done
1. List every way the floor already asks for material - Button, scan, screen, e-Kanban, 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 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 handoff that nobody owns afterward.
How a rollout is priced is on pricing. Priority configuration for busy hours sits beside the same templates under priority rules that survive a busy hour.
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.