Record each order and start fulfilment
Every order is recorded in a data store, turned into an invoice, and passed to whoever picks and packs it.
New submission on your order form
Trigger a Make scenario that writes the order to a data store, generates an invoice, and notifies the warehouse via a downstream module
One-directional. A submission triggers the action — nothing is written back into your form.
An order taken through a form is a promise to somebody. This flow makes the promise visible: the submission is written to a Make data store as a line in the ledger, an invoice is drawn up from the same values, and whoever picks and packs is told what to take off the shelf.
Small operations teams use it when orders are still arriving by email and the ledger is a spreadsheet somebody forgets to update. The form captures what was ordered; money is still collected through your invoicing tool.
Setting it up
- 1
Publish the product order form. Leave payment out of it — the form records what was ordered, and the invoice your scenario draws up is what asks for money.
- 2
In Make, create an orders data store with columns for item, quantity, variant, address and status, and set its key to the submission ID so a repeated delivery updates one row rather than adding a second.
- 3
Start the scenario with a custom webhook module, then make the data store Add/Replace a Record module the first step, so the order is on the ledger before anything else can fail.
- 4
Add your invoicing module next, building the line from Item Name or Product, Quantity and Color, Variant, or Size.
- 5
Add a router on Delivery Method so courier orders reach the dispatch module while collection orders only notify the counter.
- 6
In Zapier, choose formformform with the New Submission trigger, select the order form and pull a test submission through.
- 7
Add Make as the action app, point it at the scenario, and map the order fields — wrap Quantity in parseNumber before it reaches any invoice arithmetic.
- 8
Place one test order, check the data store row, the invoice and the dispatch notice, delete the test row, then turn the Zap on.
What maps where
Using the Product Order Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Make |
|---|---|
| Item Name or Product | Item column in the data store and the description on the invoice line |
| Quantity | Quantity on the invoice line and on the pick list, parsed as a number |
| Color, Variant, or Size | Variant column in the data store, so the warehouse picks the right one |
| Shipping Address | Delivery address on the invoice and the dispatch note |
| Email Address | Customer address the invoicing module sends to |
| Delivery Method | Router condition choosing the courier path or the collection path |
Variations worth knowing
Hold a counter key in the same data store and increment it at the top of the scenario. Passing that number to the invoice module and the dispatch note gives the customer and the warehouse the same reference to quote at each other.
Add a filter on Quantity so anything above your usual maximum takes an approval route instead of going straight to dispatch. The order is still written to the data store; it waits for somebody to say yes before a pick list appears.
If something isn't arriving
Quantity arrives as text. Wrap it in parseNumber before it reaches any arithmetic in the invoice module, and open the raw bundle in Make's run history to confirm what the value looked like when it arrived.
A retried execution wrote the record again. Set the data store key to the submission ID so the second write replaces the first, and put the dispatch module behind a check that only continues when the row was newly created.
Frequently asked questions
Can the order form take payment?
Yes. Add products and priced options to the form, then collect payment through secure hosted checkout with Stripe, PayPal, or Square. Payment status is tracked alongside the response.
Can Make write a shipped status back onto the submission?
No. The submission is a record of what was ordered and it does not change after it arrives. Keep the status on the data store row instead — the scenario owns that row and can update it at every stage of fulfilment.
How do I keep test orders away from the warehouse?
Add a filter early in the scenario that stops when the customer address matches your own domain, and place your tests with that address. Make's run history still shows the full execution, so you can check every mapping without anyone picking stock.
Related automations
- Confirm event sign-ups and log the attendee
A registration becomes a calendar entry, a confirmation email and an attendee row, all from one scenario run.
- Filter job applicants before they reach your ATS
A Make filter checks education and skills before the ATS sees the applicant, so the pipeline fills with people worth calling.
- Open a help-desk ticket and set its priority
One submission creates the ticket, sets its priority from the answer the requester picked, and drops a summary into the support channel.
- Route new leads down enterprise and nurture paths
Each lead enters a Make scenario where a router reads company size and sends enterprise deals one way, everyone else another.
- Tag feedback by score and alert on detractors
Every score is banded and logged in a data store, and anything under your threshold alerts the team straight away.
- Let only qualifying applications reach the hiring manager
A Filter step checks location and hours first, so only qualifying applications create a candidate record and reach the hiring manager.
Build the form first
The automation needs somewhere to fire from. Publish a form, connect it once, and every submission from then on runs this flow.
Start free