Automations

An automation is a rule your workspace writes: when something happens, and its conditions hold, its steps run. It moves your designs, prints and orders the way a member would, without a member being there: approve what a designer link commits, make its print file, order it, and tell the admins. The studio lists them under Automations. They come with the Pro and Business plans.

Triggers

An automation fires on one kind of event, its trigger:

• a design committed, approved, sent back for changes, or given its delivery details;
• a print file completed, or failed;
• an order submitted, moved to another status, failed, cancelled, or its delivery changed (a printshop accepted or refused a new address).

It reads the same record of events your webhooks do, so it never misses one and never acts on one that did not happen. It acts only on events from the moment it is enabled, never on what happened before, unless you apply it to a stretch of past events on purpose.

Sources

An automation acts on designs from its sources: the studio (what members make, in the studio or through Pixel) always, and designer links, your secret and publishable keys, and connected stores. Each of the three has a switch: on, it takes new ones as they come; off, it keeps to those that existed when it was switched off, a revoked one included, which makes no designs. A new automation takes every designer link and key, and no store: 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. To act on only some sources, an Only if compares where the design came from.

A store adds a design when its shopper puts it in the cart, before anything is paid, and approves it itself once the order is paid. Until the store has approved it, an automation never approves, prints or orders that design, whatever its trigger: the step is skipped, its firing says why, and the firing stops there. Designs from the studio, designer links and keys are not held back this way.

Conditions

Its conditions compare what the event is about: where the design came from, its template, tags or category, the blank and variant, the printshop, the quantity, an order’s status or why it failed, what a printshop made of an address change, whether a delivery address is given, and whether another automation caused the event. They combine with all, any and not. Without conditions, it fires on every event of its trigger in its sources.

Steps

Its steps run in order, one at a time:

• Moves: approve a design, make its print file, place an order (at the blank’s printshop or one you name), place a failed order again at another printshop, cancel an order.
• Messages: notify members, through the channels each chose (an email or a text message carries a short link that opens the page in your workspace, after signing in); email someone who is not a member, such as a printshop’s contact; call one of your webhook endpoints with a JSON body you write. That request’s type is automation.webhook.
• Flow: go on only if a condition holds, take one of two paths, wait for a print file or an order to reach a state (with a timeout, at most 30 days), or wait a while.

A step that fails at once can have its own on failure steps. Texts take placeholders, such as {order.id} or {printshop.contact.email}, filled in when the step runs.

Before an automation is saved, it is checked: each step says, for every printshop it may reach, whether it can act there, cannot and why, or can only while a condition holds. A step that can act nowhere refuses the save.

Firings

Each time an automation matches an event is a firing. A firing is running, waiting, paused, succeeded, failed or cancelled, and each of its steps is done, skipped, blocked, failed or retrying, always with a reason. A firing finishes on the version of the automation it started on: editing an automation changes later firings only. A step that fails for a moment is retried; one that is refused is not.

A move that has already happened, because a member or another automation made it first, is skipped: already done, never done twice. A message is sent once per chain of events: when two automations would send the same email to the same address about the same order, the second is skipped, naming the first.

Firings are kept 90 days. A member may retry a failed firing from its failed step, resume a paused one, and cancel a waiting one.

Authority

An automation acts with the permissions of its author, the member who last saved it, checked again at every firing: you can only automate what you may do yourself. When the author loses a permission it needs, the automation is broken until someone who has it saves it again. An admin may instead have it run as the workspace, tied to no member; one made with a secret key always runs so.

Whatever it does is recorded as done by the automation, by its name, and the events it causes say so (via: "automation").

Spending

Making a print file, placing an order and placing one again elsewhere are spend actions. Saving an automation that holds one confirms what it may spend without a person. Each automation has a spend limit, spend actions per rolling 24 hours (50 unless you set another), and the workspace has a ceiling across all its automations. A firing that would pass either is paused, not dropped, and the workspace is told; a member resumes it.

What an automation never does

An automation never writes to a customer. An email step reaches people who are not members, never the person an order is for: an address that is an order’s recipient’s is refused when the automation is saved and blocked when it runs. Talking to your customers is yours to do. Their name and address reach only the order’s own printshop.

A custom printshop’s own delivery steps are not automations: they run for every order it takes, however it was made, and cannot be switched off.