Drag steps onto a canvas, branch on any field, and map data between steps with typed references, so the integration you draw is the integration that runs.
Why teams switch
Every new carrier, retailer, and client means another integration someone has to build and babysit. Generalist iPaaS tools make you teach them what a rate, a label, or an 856 is. The integrations that move orders, labels, and partner documents are the ones a fulfillment business cannot afford to lose. They are also the ones most often held together by scripts and goodwill.
Your order sync is a cron job and a folder of scripts. It works until the person who wrote it is on holiday.
With Flows: Flows replaces it with a drawn flow: versioned drafts, a dry run against a real captured payload, and a run history anyone on the team can read.
A general-purpose iPaaS knows HTTP and JSON. Rate shopping, buying a label without overdrawing, or producing an 856 your retailer accepts is work your team builds and guards.
With Flows: In Flows those are single steps, and the rules that protect your money are enforced by the platform, not by whoever configured the integration.
The canvas
Flows is the third Orderly product, beside Hub and Intelligence. It works on the same orders, shipments, inventory, and carrier accounts, so a flow acts on your operation directly instead of syncing a second copy of it.
Orderly
orderly.order.getorderly.order.ingestorderly.shipment.getorderly.inventory.lookuporderly.rateorderly.label.purchaseorderly.pickup.scheduleorderly.claim.createData
transform.parsetransform.mapcollection.filtercollection.aggregateConnectors
exchange.sendhttp.requestbridge.taskControl
branchwait.eventrespondData mapping
Mapping happens in the field you are editing, not in a separate tool. Reference the trigger payload or any earlier step's output, reshape it with a function, and translate codes against your own tables.
Type {{ in any field and the designer offers exactly what the trigger and earlier steps produce, with payload keys learned from your endpoint contract, a captured payload, or the latest run.
Reshape values on the way with functions for text, math, dates, lists, and lookups, such as {{ upper(trigger.payload.state) }}, without leaving the field you are mapping.
Field rules with defaults, required checks, patterns, and date masks, across CSV, XML, JSON, and fixed-width.
Map, filter, aggregate, sort, and dedupe up to 1,000 items in one step. JavaScript is there when you need it, sandboxed and bounded to one second.
Up to 50 tables of 50,000 rows each, imported from CSV, for carrier codes, SKU maps, and warehouse routing. Translate a code with lookup('carrier-codes', …) against your own tables.
Read CSV, XML, or JSON text into data, or write it back out, up to 1 MB and 10,000 rows, with no mapping to build first.
Error handling
Decide in the designer what happens when a step fails, before it fails in production. Whatever you choose, a run that cannot recover opens an exception your team can retry, as described on the reliability page.
Give any step a retry policy of up to 10 attempts with a backoff that doubles each time. Only failures that can succeed on another try, such as timeouts, rate limits, and outages, are retried.
Attach a handler lane of up to 20 steps that runs when a step fails for good, to alert someone, record the problem elsewhere, or fall back, then continue or fail the run as you choose.
Purchase label and Schedule pickup can never be set to skip on error or be swallowed by a recovery lane. Publishing refuses a flow that tries.
Versions and testing
Every step validates its configuration before you can publish. Drafts are versioned, so you edit while the published version keeps running, and a dry run replays a real payload captured from a recent run or endpoint request.
Edit a draft while the published version keeps running. Runs already in progress finish on the version they started with, and History restores any earlier version as a draft.
Publishing compares the draft with the live version, step by step, and refuses a draft with known problems, such as a reference to a later step, a missing lookup table, or a money step set to skip.
A dry run replays a real payload captured from a recent run or endpoint request and paints each step with its result. Steps that write data, call carriers, or spend money only resolve their configuration.
What you build with it
Brands and shippers
When an order lands, quote it across your carrier accounts, branch on weight or service level, buy the label, and post tracking back to the store. Funds are held before any carrier is called, so the flow can never overdraw your balance.
order_createdorderly.ratebranchorderly.label.purchasehttp.requestQuestions
A generalist iPaaS is built to connect anything, so logistics behavior is something your team designs on top of it. Flows is built on Orderly's own orders, shipments, carrier accounts, and claims: rate shopping, label purchase, pickup, and X12 documents are single steps, and the money rules are enforced by the platform. If most of what you integrate is fulfillment, you start further ahead. If you integrate HR, finance, and CRM systems too, a generalist platform may suit you better.
No. Steps, references, mappings, branches, and list operations are configured in forms on the canvas, and every flow can also be edited as JSON. When a transformation genuinely needs code, the JavaScript transform step runs it in a sandbox with a one-second limit.
Yes. A dry run walks the flow against a sample payload, such as one captured from a recent run or endpoint request. Steps that write data or call outside systems, including Rate shop, Purchase label, Send exchange document, and HTTP request, only resolve their configuration, so nothing is written and no money moves.
Draw your first flow
Tell us what it does today, and we will show you the same integration as a flow your whole team can read.