Skip to content

article

Workflow Recipes: Common Automations You Can Copy

Six ready-to-adapt automation recipes spanning CRM, Mail, Shop, Books, Support, and Schedule — each with its trigger, steps, and the data that flows between them.

How to use these recipes

Each recipe below lists the trigger, the steps (with connector, action, and dependencies), and the data that flows between them. Build one by creating the workflow, adding the steps with the given keys, wiring the dependencies, then validating and simulating with a realistic trigger payload before you activate. Adapt the field names to your own data. All of these use only built‑in StretchSuite connectors.

Recipe 1 — New lead welcome

Goal: greet every new CRM lead instantly.

  1. Trigger: App event — StretchCRM lead_created.
  2. welcome_email — action, StretchMail send_email, recipient {{ trigger.email }}, personalized with {{ trigger.name }}. Depends on the trigger.

Simulate with a sample lead, confirm the recipient resolves, then publish. Optionally add add_to_list (StretchMail) depending on welcome_email to enroll them in a nurture sequence.

Recipe 2 — Abandoned cart win-back

Goal: recover higher‑value abandoned carts.

  1. Trigger: App event — StretchShop cart_abandoned.
  2. worth_recovering — filter, passes when {{ trigger.cart_total }} exceeds your threshold. Depends on the trigger.
  3. reminder_delay — delay (e.g. one hour). Depends on worth_recovering.
  4. reminder_email — action, StretchMail send_email to {{ trigger.customer_email }}. Depends on reminder_delay.

Because steps 3–4 depend on the filter, low‑value carts skip the whole branch. Simulate one passing and one failing cart to confirm.

Recipe 3 — Paid invoice thank-you and tag

Goal: thank paying customers and mark them in CRM.

  1. Trigger: App event — StretchBooks invoice_paid.
  2. thank_you — action, StretchMail send_email to {{ trigger.customer_email }}. Depends on the trigger.
  3. tag_paying — action, StretchCRM add_tag (tag: paying‑customer) for {{ trigger.customer_id }}. Depends on the trigger.

Steps 2 and 3 both depend only on the trigger, so they run together in one stage. Simulate a paid‑invoice payload and check both resolved.

Recipe 4 — High-value order → VIP handling

Goal: give big orders white‑glove treatment.

  1. Trigger: App event — StretchShop order_created.
  2. is_vip — filter, passes when {{ trigger.total }} exceeds 500. Depends on the trigger.
  3. tag_vip — action, StretchShop tag_customer. Depends on is_vip.
  4. manager_task — action, StretchTasks create_task ("Personally follow up on order {{ trigger.order_id }}"). Depends on is_vip.
  5. standard_thanks — action, StretchMail send_email. Depends on the trigger (runs for every order).

Validate and confirm the plan puts tag_vip and manager_task behind the filter while standard_thanks runs unconditionally.

Recipe 5 — SLA breach escalation

Goal: never miss an imminent SLA breach.

  1. Trigger: App event — StretchSupport sla_breach_imminent.
  2. escalation_task — action, StretchTasks create_task ("Escalate ticket {{ trigger.ticket_id }}"). Depends on the trigger.
  3. notify_customer — action, StretchSupport reply acknowledging the delay on {{ trigger.ticket_id }}. Depends on the trigger.

Both actions depend on the trigger and run together. Simulate with a sample breach event to confirm the ticket id flows into both steps.

Recipe 6 — Appointment booked → prep and confirm

Goal: prepare for every booked appointment.

  1. Trigger: App event — StretchSchedule appointment_booked.
  2. prep_task — action, StretchTasks create_task ("Prepare for {{ trigger.customer_name }} at {{ trigger.start_time }}"). Depends on the trigger.
  3. confirm_email — action, StretchMail send_email to {{ trigger.customer_email }} confirming the time. Depends on the trigger.
  4. add_to_calendar — action, StretchSchedule create_event mirroring the booking for the team. Depends on the trigger.

All three actions share the trigger dependency and run in one stage.

Tips

  • Start from the closest recipe and change field names and thresholds rather than building from scratch.
  • Add a filter whenever "only when …" appears in your requirement, and depend the conditional steps on it.
  • Keep unconditional steps (like a universal thank‑you) depending on the trigger, not on a filter.
  • Simulate every recipe with representative data before activating — especially the passing and failing paths of any filter.

FAQ

Can one workflow have multiple triggers? No — each workflow has a single trigger. Build separate workflows for separate trigger events.

Can steps run in parallel? Steps that share the same dependencies land in the same execution stage and are handled together — that's your parallelism.

How do I stop a recipe temporarily? Set the workflow's status to Paused; re‑activate when you're ready. The definition is preserved.

Was this helpful?

Help us improve this article

Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.