Cresca Automation Guide: Building Workflows That Do Not Break
Email automation is easy to start and hard to get right. A workflow that sends twice, or sends to someone who already converted, is worse than no automation at all. This guide covers how automation works in Cresca and the specific mistakes that cause problems in production.
The three building blocks
Every workflow is made from the same parts.
Triggers start a workflow. A trigger is an event: a contact is added, a form is submitted, a link is clicked, a purchase is recorded, a date is reached. The important property of a trigger is that it is an event, not a state. This distinction causes more bugs than anything else in automation.
Conditions decide whether a contact continues down a path. They read the contact's current data: plan, location, tag, engagement history. Conditions are evaluated at the moment they are reached, which means a contact's path can change based on a purchase they made two days ago.
Delays pause the workflow. A delay of three days means the next step runs three days after the previous one, not at a fixed clock time. This matters when you chain delays, because the total elapsed time depends on when the contact entered.
The event versus state distinction
This is the single most common source of broken automation, so it is worth stating carefully.
If your trigger is "contact has tag: trial", that is a state, not an event. A contact who already had that tag when you activated the workflow will not trigger it, and a contact who gains it later will. Whether they enter depends on timing rather than on their behaviour, which is rarely what teams intend.
If your trigger is "tag added: trial", that is an event. It fires once, when the tag is applied. This is almost always what you actually want.
Audit every trigger in your account against this test. Triggers that read as states are a latent source of both missed sends and unexpected ones.
Avoiding duplicate sends
Duplicate sends almost always come from one of three causes.
- Overlapping triggers. Two workflows both trigger on "contact added" and both send a welcome email. The contact gets two. Fix by consolidating into one workflow with conditions for the branches.
- Re-entry. A contact can re-enter a workflow if they meet the trigger condition again. For a welcome series this is usually wrong; for a re-engagement campaign it may be exactly right. Set re-entry explicitly rather than leaving the default.
- Retries without idempotency. If an external event is delivered twice, a workflow triggered on it may run twice. Cresca's sending runs through a queue that records permanent failures and does not re-send them, but the workflow itself should still be designed so that processing the same event twice is harmless.
Testing before going live
Do not activate a workflow and watch what happens to real contacts. Test it on a controlled set first.
- Create a test contact and give it the trigger condition.
- Walk the workflow step by step and confirm the entry condition fires exactly once.
- Check the delay arithmetic: write down the expected send timestamps and compare against what the workflow reports.
- Test the exit conditions. If a contact purchases mid-sequence, does the workflow stop? If it does not, you are sending a promotional email to someone who just bought.
- Run a second test contact through immediately after the first, and confirm the two do not interfere.
Designing for failure
Automation runs unattended, so design it to fail safely.
Keep each workflow narrow. A workflow that handles trial onboarding, reactivation and upsell in one graph is hard to reason about and hard to debug. Three separate workflows with clear entry conditions are easier to verify and safer to change.
Add an exit condition for every sequence. The most common automation embarrassment is a nurture sequence that keeps sending after the contact has already signed up.
Name everything. A trigger called "Form submitted" when you have fourteen forms is unmaintainable six months later. Name the workflow, the trigger and the exit conditions in terms of the business outcome.
Measuring whether it works
Judge automation on the outcome the workflow exists to produce, not on email metrics. A welcome series exists to move new contacts toward activation; measure activation. A cart abandonment workflow exists to recover revenue; measure recovered orders.
Intermediate metrics are still useful for diagnosing where a workflow loses people, since they tell you which step is failing. Use clicks and conversions for this rather than opens, which are inflated by client-side image proxying and prefetching and cannot be compared reliably across audiences.
Pricing
Automation workflows are included on every paid plan:
| Plan | Price | Contacts | Emails / month |
|---|---|---|---|
| Free | $0 | 50 | 50 |
| Professional | $29/mo | 5,000 | 5,000 |
| Premium | $49/mo | 25,000 | 25,000 |
| Ultra | $99/mo | 55,000 | 55,000 |
Analytics for workflows
A workflow needs different reporting from a campaign. A campaign has one send and a result. A workflow is a pipeline, and the useful view is where people drop out.
Look at each step in order and ask what share of contacts who entered the step completed it. A dramatic fall between two steps usually means a poorly timed message rather than a badly written one: if the second email in a welcome series loses most of its audience, the delay is probably too long, or the first email already accomplished the goal.
Attribution is genuinely hard for automation. A contact who receives four emails and then converts did so after the fourth, but the sequence as a whole deserves the credit. Report on the cohort that entered the workflow and the conversion rate of that cohort, rather than assigning each order to the last email before it.
When to rebuild rather than patch
Workflows accumulate conditions over time as requirements change. A graph that has been edited for a year usually contains branches nobody can explain and conditions that no longer correspond to anything real.
The signal to rebuild is when you cannot answer, without tracing it, what a specific contact will receive after entering. At that point the workflow is a liability: nobody can safely change it, and failures are hard to diagnose. Rebuild it from the entry condition forward, keeping only the steps whose purpose you can state in one sentence.
Deliverability inside automation
Automation sends to contacts who may not have engaged for a long time, which is where deliverability problems appear. A re-engagement sequence firing at contacts who have not opened anything in a year is, from a mailbox provider's perspective, an unengaged list being mailed at volume.
Suppress bounces and complaints before they enter a workflow, and consider splitting a reactivation campaign so that the first message goes to a smaller group. If a workflow systematically mails unengaged contacts, it will affect the reputation of everything else you send from the same domain, not just that workflow's own messages.
The short version
Triggers are events, not states: "tag added", not "has tag". Set re-entry behaviour explicitly. Consolidate overlapping workflows rather than letting two of them send the same email.
Test on controlled contacts, checking entry, timing, exit conditions and repeat-run safety. Keep workflows narrow, always define an exit, and measure the business outcome rather than the open rate.
Continue learning
Related Cresca resources
External references