Fulfillment App
The Fulfillment App is Carriyo's standalone application for the people physically handling parcels: warehouse staff, store fulfillment staff, and customer-collection counter associates. Where the Dashboard is the ops manager's tool spanning every location in the tenant, the Fulfillment App is the picker's, packer's, and handover associate's tool scoped to one location at a time.
It runs as a Progressive Web App, installs on mobile and tablet, and is designed for hand-held use on the floor with barcode scanning baked into every workflow.
The Fulfillment App is for clients running their fulfillment through Carriyo, whether the location is a warehouse, a store, a dark store, or any other facility. If your fulfillment runs outside Carriyo on your own systems, the platform updates Fulfillment Order state from your events instead and the App isn't part of the flow.
Single-location context
Every screen in the Fulfillment App lives under a URL of the shape:
/tenants/{tenantId}/locations/{locationId}/...
The active warehouse or store is part of the URL, not the user's session. This is the app's defining constraint: every API call it makes resolves against exactly the location in the path. Operators working across multiple locations switch by opening a different location URL (typically via a bookmark, QR-code shortcut, or account-switcher).
The app refuses to load until both tenant and location are present in the URL.
What the Fulfillment App does
The workflow areas map to the runtime entities described under Fulfillment:
| Screen | Purpose |
|---|---|
| Home | Cross-entity search and operator landing page |
| Orders | The queue of fulfillment orders allocated to this location, with drill-in to each |
| Picks | Pick queue, item-by-item scan, mispick capture. See Pick |
| Packs | Pack queue, packing-station check-in, multi-parcel build with dimensions and weight. See Pack |
| Ship | Carrier handover scan, manifest upload, shipment detail |
| Collect | Customer-collection handover with OTP verification. See Customer collection |
| Customer | Customer lookup for collection orders |
| Settings | Per-location admin: packing stations, bin locations, ship zones, printers, system flags, users |
| Profile | Sign-out, language, theme, device preferences |
The Pick, Pack, Ship, Collect, and Customer screens are the day-to-day work. Settings is touched once or twice per location during setup and rarely revisited.
Per-location configuration
Each location carries its own Fulfillment App settings, edited under Settings → System:
- Simple Mode. Skip the Pick step entirely and jump straight to Pack. Used by stores that don't run a separate picking workflow.
- Auto-create picks. Pick records are generated automatically for incoming fulfillment orders, ready for an operator to claim.
- Split picking. One fulfillment order across several Picks (multiple pickers tackle different sections of one order).
- Cluster picking. One Pick across several fulfillment orders (one picker collects items for multiple orders in one walk of the floor).
- Picker assignment. Operators self-claim from the queue, or the system assigns based on current workload.
- Mispick handling. When a picker records a mispick, either cancel the item from the order, or move it to a new fulfillment order so it can be picked again from elsewhere.
- Allow without scan. Per-stage escape hatches for Pick, Pack, and Ship, for situations where a scanner isn't practical. Off by default.
- Confirmation countdowns. 1–5 second hold on Pick, Pack, and Ship confirmations, configurable per stage. Default is 3 seconds; guards against accidental confirms.
Bin locations, packing stations, printers, and ship zones are also per-location and managed from the same Settings module.
Roles and permissions
The Fulfillment App has its own role model, parallel to the
Dashboard's, not derived from it. A user can hold an admin
role in the Dashboard and a store-operator role in the
Fulfillment App, or be granted access to only one of the two.
Two app-level roles:
| Role | Typical user |
|---|---|
store-operator | Picker, packer, ship counter, collection counter: the people physically handling parcels |
store-admin | Store / warehouse lead: operator capabilities plus configuration of bin locations, packing stations, ship zones, and Fulfillment App settings |
The naming (store-*) is historical; both roles belong to the
current Fulfillment App, not to any legacy app.
Inside the app, the role drives fine-grained permissions across the workflow areas: orders, picks, packs, shipping, customer collection, customer lookup, and admin. Each permission is granted per location and at one of several progressively broader levels, from read-only browse through to full edit. A picker on a warehouse floor might be limited to picks at one location; a store lead might hold every permission at every location they cover.
Sign-in and device setup
Operators sign in through the same identity-provider flow as the Dashboard, with token refresh handled silently in the background. The app identifies itself to the auth layer so role resolution picks up the Fulfillment App role, not the Dashboard role, for the same user.
Because the active location is encoded in the URL, each device
typically uses a device-specific bookmark or QR-code
shortcut pinned to the hardware. Each device's shortcut points
at the /tenants/.../locations/.../ URL for that spot. Once
installed as a PWA, the device keeps the user signed in across
launches via the shared session cookie.
Installation is prompted automatically on first visit from a supported mobile or tablet browser. The installed app runs full-screen, hides browser chrome, and caches the application shell so launching is near-instant.
Scanning and the warehouse floor
Barcode scanning runs through the device's built-in camera. No native scanner SDK, no third-party hardware integration. The same search field accepts either typed input or a scan, so operators scan SKUs, parcels, packing stations, and ship-zone labels with nothing more than the device they're already using.
Every confirmation step (pick complete, pack complete, ship handover) holds a 1–5 second countdown (configurable per location). The hold gives an operator a window to cancel a mis-tap before it commits.
The "allow without scan" location settings are an escape hatch, not the default workflow. The app expects barcoded items, parcels, and stations as the primary input.
Fulfillment App vs Dashboard
Both apps share the same backend and the same Pick, Pack, Ship, and Collection records. The difference is the audience and the scope.
| Fulfillment App | Dashboard | |
|---|---|---|
| Scope | One location at a time | All locations in the tenant |
| Audience | Floor staff: pickers, packers, counter associates | Ops managers, admins |
| Primary input | Barcode scan | Click and type |
| Form factor | Mobile / tablet PWA | Desktop browser |
| Role model | store-operator, store-admin (parallel) | viewer → super-admin |
Overlap zones (either tool can do it): create / cancel Picks and Packs, view shipments, confirm carrier handover, run customer collection handover, edit per-location packing stations, bin locations, printers, ship zones.
Fulfillment App only: live barcode scanning, per-station packing check-in with countdown confirmation, OTP-prompted collection handover, PWA install for floor devices, single-location URL.
Dashboard only: tenant-wide reporting, carrier configuration, shipping rules and service levels, manifest/label policies, integrations and webhooks, user management at tenant scope (the app's Users tab is per-location), all merchant-portal and customer-portal configuration.
Relation to the legacy Store App
A previous-generation Store App is being decommissioned. The
Fulfillment App is its successor, with a broader scope covering
the full warehouse fulfillment workflow (not only store
operations). Existing Store App users will be migrated on a
published cadence; until migration is complete, both may coexist
for some tenants. The store-operator / store-admin role
names are kept by the new Fulfillment App for continuity.
How it fits with other modules
- Fulfillment. The Pick, Pack, and Collection data model the app operates on.
- Account model. The Fulfillment App's role model is parallel to the Dashboard's; both are bound to the same tenant and user identities.
- Orders. The app operates on fulfillment orders allocated to its single location.
- Customer collection. The entity behind the app's Collect workflow.
- Fulfillment API. The API the app calls.