Automate with automations

An automation moves your designs, prints and orders when something happens, the way a member would: approve what a designer link commits, make its print file, order it at your printshop. This guide makes one, tries it, switches it on and follows what it does. Automations come with the Pro and Business plans; admins make and change them, and every member can read them.

Make one from a recipe

Under Automations, New automation offers the recipes, each a ready automation you change afterwards like any other:

• Approve on commit: every design committed from where you choose is approved at once.
• Print on approve: an approved design gets its print file.
• Order on print: a ready print file is ordered at the printshop you choose.
• Hosted link to printshop: a design committed through a designer link is approved, printed and ordered, and the admins are told, or told when its print file is late.
• Failover to another printshop: an order that fails at one printshop is placed at another, once. It needs two printshops taking orders, and two different ones.
• Refused address change: when a printshop refuses an address change, its contact is emailed.
• Start from nothing: no trigger and no steps; you add them.

Create makes it at once, named Automation 1, Automation 2 and so on, and opens it on its steps. Rename it in its settings, and fill in what the recipe asks for: the printshop or printshops it orders at. Saving it checks that nothing is missing. A recipe the workspace cannot use yet says why.

Every automation is made disabled. It does nothing until you switch it on, so you can look it over first. One with no trigger yet fires on nothing, and cannot be switched on until you pick one.

It acts on designs from the studio, every designer link and your keys. Under Sources on its trigger, Include new designer links and Include new keys are on; switch one off and it keeps to the designer links, or the keys, that existed that day. Include new stores is off: a connected store may have its own automated flows, and an automation acting on its designs competes with them, the first to move a design on winning. Turn it on to act on them too, and the pane warns you of that. A store’s design still in a shopper’s cart is never approved, printed or ordered by an automation: those steps skip it until the store approves it once the order is paid, and the firing says so. The pane says this too, when the automation’s steps approve, print or order. To act on only some sources, add Only if: Where the design came from, which follows the trigger.

With the API, GET /v1/automations/recipes lists the recipes, with whether your workspace can use each, and POST /v1/automations/recipes/{id} makes one. POST /v1/automations makes one from nothing, and PUT /v1/automations/{id} saves its next version. A draft the check refuses is answered with each reason and the step it is about.

Test it

A test run replays an automation on one past event of its trigger and does nothing: no design is approved, no order placed, nothing sent. It says whether the automation would fire, each condition with the values it compared, and each step it would run or why that step would be blocked, with its texts filled in. A wait does not wait.

POST /v1/automations/test-run/events finds the newest events to test on, and POST /v1/automations/test-run runs it, on a saved automation or on a draft before you save it. Pixel can do both for you in the studio: ask it to test-run the automation on the last order that failed.

Switch it on

Switch the automation to Enabled when the test run does what you meant. From then on it acts on every event of its trigger in its sources, without a person. It never acts on what happened before it was enabled; to apply it to a stretch of the past, POST /v1/automations/{id}/past-events fires it on a window of at most 30 days and 500 events, shown first as a test run of the newest.

Disabling it stops it, and cancels the firings still waiting.

Pixel can make and edit a disabled automation for you, and test-run it. To switch one on, or to change one that is on, it shows you a card, and nothing changes until you press it. An AI assistant connected over MCP can read, test, make and edit disabled automations, but never switches one on.

Read its firings

Each time an automation fires, its firing says what it acted on, the step it got to, and why it stopped. Open the automation’s Firings tab, or read GET /v1/automations/{id}/firings and one firing by its id. Each step is done, skipped (already done by someone, or already sent), blocked with the reason, failed, retrying, or waiting.

When a firing fails, the automation is failing until one succeeds, and the members who read automations are told once. Retry a failed firing from its failed step once you have fixed what stopped it; resume a paused one; cancel one that is waiting.

Keep what it spends in bounds

Making a print file, placing an order and placing one again elsewhere are spend actions. Saving an automation that holds one asks you to confirm that it spends without a person (confirmSpend with the API).

• Each automation has a spend limit: spend actions per rolling 24 hours, 50 unless you set another (spendLimit).
• The workspace has a ceiling across all its automations, under the automations’ settings.

A firing that would pass either is paused before it spends, never dropped, and the workspace is told. A member resumes it once they have looked. A metered action spends credits as it would for a person.

In a sandbox

A sandbox runs automations too. Sync from live copies each of your live automations into it disabled, so you switch on the ones you want to try there; the next sync replaces them with live’s again. Orders stop at submitted as any sandbox order does, notifications and webhooks are sent, and an email to someone who is not a member is not: its step is done, with the message it would have sent.