Start Automation – Automation Step

Overview #

The Start Automation step triggers another automation for the current contact from within the flow you are building. It’s a clean way to reuse existing automations (e.g., onboarding, re-engagement, surveys) without duplicating steps.

Think of it as: "Run that other automation now for this same contact." The current automation continues after this step unless you explicitly design an early exit.

Why Use Start Automation? #

✅ Reusability – Centralize common sequences in dedicated automations
✅ Composability – Build flows from smaller, maintainable building blocks
✅ Consistency – Ensure the same logic is applied everywhere
✅ Separation of concerns – Keep main flow lean; offload sub‑journeys
✅ Faster iteration – Update a single automation to improve all callers

---

How to Add a Start Automation Step #

Step 1: Select the Action Type #

1. In your automation builder, click "Add Action" or the "+" button
2. Choose "Start Automation"

Step 2: Choose the Automation #

After adding the step, you’ll see a searchable dropdown with your automations:

• The list shows all available automations except the one you’re currently editing (to avoid recursion)
• Use the search box to find an automation by name
• Pagination loads more items as needed
• Select the automation you want to start

When selected, the step becomes valid and can be saved.

---

How It Works #

When the flow reaches a Start Automation step:

1. The selected automation is triggered for the current contact
2. That automation runs according to its own configuration and rules
3. Your current automation then continues to the next step (they can run in parallel from a user perspective)

Key points:

• The new automation runs with the contact’s current data at the time of triggering
• If the target automation has manual‑start constraints or warnings, those apply when it is run manually; they don’t block this step from triggering it programmatically
• Both automations can update contact fields, tags, lists, tickets, etc.; design with idempotency in mind

---

Practical Examples #

Example 1: Multilingual Onboarding #

If/Else: Check language
  IF Italian → Start Automation: Onboarding (IT)
  IF Spanish → Start Automation: Onboarding (ES)
  ELSE → Start Automation: Onboarding (EN)
Continue current flow → Tag "onboarding_dispatched"

Example 2: Survey After Issue Resolution #

Resolve ticket → Start Automation: CSAT Survey → Continue

Example 3: Payment Flow Composition #

Start Automation: Payment Request
Delay: 24h
If/Else: If paid → Continue
        Else → Start Automation: Payment Reminder

---

Best Practices #

• Keep automations atomic: Design target automations to accomplish one clear purpose (onboarding, CSAT, recovery)
• Avoid circular triggers: Don’t create loops where Automation A starts B and B starts A
• Guard shared resources: If multiple automations write the same fields/tags, ensure the logic is idempotent
• Name clearly: Use consistent, descriptive names (e.g., “Onboarding (IT)”) so they’re easy to select
• Version responsibly: If you plan large changes, clone automations and phase in the new version
• Monitor impact: Starting an automation can send messages; confirm compliance with 24‑hour WhatsApp windows

---

Limitations & Considerations #

• You cannot select the automation you’re currently editing
• The called automation runs independently; this step does not wait for it to finish
• Both automations may act concurrently on the same contact—plan for race conditions (e.g., use tags/state fields to coordinate)
• If the target automation has prerequisites (required fields, tags), ensure they are set before starting it
• Respect message sending rules (e.g., free‑message 24h window vs templates)

---

Troubleshooting #

The automation doesn’t appear in the dropdown #

• Ensure it exists and you have permission to view it
• Clear search text to reload the full list
• Scroll/load more to fetch additional pages
• You can’t select the current automation

It started, but messages didn’t send #

• Check warnings and rules inside the target automation (e.g., free‑message windows)
• Verify required data is present (custom fields, tags)
• Review execution logs for both automations

Conflicting updates between automations #

• Use tags/fields as state flags to coordinate
• Split responsibilities: one automation writes fields, the other reads
• Add short Delays to avoid race conditions if needed

---

Design Patterns #

Pattern 1: Orchestrator + Workers #

Use a “master” automation that starts specialized sub‑automations:

Orchestrator → Start Automation: Lead Enrichment
            → Start Automation: Qualification
            → Start Automation: Nurture (EN/IT/ES via Branching)

Pattern 2: Re‑usable Surveys #

After any service completion → Start Automation: CSAT Survey

Pattern 3: Multi‑Step Recovery #

Start Automation: Payment Request
If unpaid after delay → Start Automation: Payment Reminder
If still unpaid → Start Automation: Assistance Handoff

Pattern 4: Conditional Handoff #

If/Else: High LTV AND VIP tag → Start Automation: VIP Concierge
Else → Continue standard flow

---