Automations

Automations lets your team design repeatable ministry follow-up flows, then run them consistently with built-in processing, retries, and execution tracking.

What Automations Handles

• Event-based follow-up (for example, new visitor form submitted).
• Trigger-driven journeys from templates or blank workflows.
• Branch-level execution with status controls (draft, active, paused, archived).
• Delayed steps and conditional routing.
• Centralized sending through the communication outbox.
• Runner health, lease ownership, and processing status.

Core Building Blocks

Automations are composed of:

• Trigger nodes to start the workflow.
• Condition nodes to branch by available data.
• Delay nodes to schedule later steps.
• SMS / Email action nodes to queue outbound communication.

Supported trigger choices include:

• Manual
• Visitor submitted connect form
• Invite link clicked
• Member created
• Donation recorded

Automation Runner (How Processing Happens)

The Automation Runner is the branch-level processor that handles:

• Trigger events waiting to be processed.
• Delay jobs waiting for their scheduled time.
• Outbox messages waiting to be sent.

Runner status panel shows:

• Whether runner is enabled.
• Leadership state (Leader / Standby).
• Last tick timestamp.
• Current lease owner and lease expiry.

When runner is disabled, non-manual automation events will not progress.

Create a New Automation

Automation Builder (Visual Editor)

After you create an automation, you can open the Builder to shape the full journey visually.

Think of the Builder like a map:

• Each block is a step.
• Lines show the path a person can take.
• You can click any block to edit that step.

The page is designed so non-technical teams can build, review, and improve journeys together.

What You Will See in Builder

1) Canvas area

This is where your automation path appears.

You can:

• Select a step
• Move a step
• Connect one step to another
• Zoom in/out for easier editing

2) Step settings panel

When you select a step, the side panel shows its settings.

Examples:

• SMS step: message text
• Email step: subject and body
• Delay step: how long to wait
• Condition step: how to route people down different paths

3) Utility controls

Builder controls help you work faster:

• Undo / Redo
• Zoom controls
• Mini-map
• Quick actions for adding steps

Adding and Editing Steps

Common flow pattern:

1. Start with Trigger.
2. Add a message step (SMS or Email).
3. Add Delay if needed.
4. Add Condition if you want branching.
5. Continue until your follow-up path is complete.

Tips for clear journeys:

• Keep step names short and clear.
• Build one goal per automation when possible.
• Use delays only where timing truly matters.

Running Safely from Builder

Builder supports multiple run modes so teams can validate before sending real messages.

• Preview: safest check, no run history.
• Test: safe check with logged results.
• Live: real sending mode.

Live mode includes extra confirmation prompts to reduce accidental sends.

Runs Tab (Reviewing Outcomes)

The Runs area helps your team review what happened after a test or live run.

You can:

• Open run details
• See which steps completed
• Spot failed steps quickly
• Retry failed sends when available
• Stop an active run if needed

This makes troubleshooting easier during rollout.

Template Manager in Builder

Builder includes a built-in template manager so you can reuse successful journeys.

Tabs include:

• Browse
• My templates
• Save
• Import/Export

Practical uses:

• Save your best-performing workflow as a reusable template.
• Apply a template to start faster for a new ministry process.
• Share team-approved patterns for consistency.

Builder Best Practices for Non-Technical Teams

• Start simple; add complexity only after first success.
• Test every new automation before activation.
• Keep message tone consistent with your church voice.
• Review early runs as a team and improve timing/content.
• Archive outdated workflows to keep the list clean.

Templates

Templates accelerate common workflows, such as:

• Visitor welcome and first follow-up sequences.
• Invite engagement nurture journeys.
• Giving follow-up and thank-you paths.
• Member onboarding communication flows.

Template selection shows summary information so teams can choose by intended outcome quickly.

Automation Status Lifecycle

• Draft: Can be designed and tested, not intended for live event-driven runs.
• Active: Eligible to run for matching triggers.
• Paused: Temporarily stopped.
• Archived: Retained for history, not actively run.

Switching status is available directly from each automation card.

Manage Existing Automations

From each automation card, teams can:

• Activate / Pause.
• Edit metadata (name, description, trigger).
• Open builder.
• Delete automation.

Deleting is permanent and intended for obsolete flows only.

Trigger Event Flow

For event-driven automations, the processing chain is:

1. Source event occurs (for example invite click or visitor submission).
2. Event is queued in automation events.
3. Runner claims pending events in batches.
4. Matching active automations are started.
5. Workflow executions are recorded node by node.

If one automation fails during an event cycle, failure is captured for review while preserving traceability.

Delay and Resume Flow

Delay nodes do not block the UI. Instead they:

• Create scheduled automation jobs.
• Resume execution at the next node when run time is reached.
• Retry with backoff on failure.

This supports long-running journeys without keeping a single execution thread open.

Outbox Sending and Retry Behavior

SMS/Email action nodes enqueue outbox messages, then the runner:

• Claims pending messages.
• Attempts channel delivery via configured gateway.
• Marks sent messages with delivery details.
• Retries failed sends with increasing backoff.

This keeps delivery resilient in unstable network or provider conditions.

Execution Visibility and Diagnostics

Automations includes command-level support for:

• Previewing automation execution before live use.
• Listing runs and run details.
• Inspecting run outbox messages.
• Retrying failed outbox messages.
• Stopping active runs when needed.

These controls are useful for rollout, QA, and incident response.

Safety and Governance Notes

• Trigger context is validated before execution.
• Required data differs by trigger type (for example invite token for invite-click events).
• Pausing/archiving includes safeguards to stop in-flight queued work where possible.
• Runner lease prevents multiple devices from processing the same branch simultaneously.

Recommended Rollout Pattern

1. Start from a template.
2. Preview and test with safe sample context.
3. Activate one workflow at a time.
4. Watch first live run logs and outbox behavior.
5. Scale to additional journeys once baseline reliability is confirmed.