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 completed connect form
• Member created
• Donation recorded

Invite Campaigns already track link clicks and form submissions for reporting and attribution. In Mailchimp terms, that reporting is separate from the journey starting point. Because of that, Holy Resource now keeps invite_clicked as a supported legacy trigger for older workflows, but the normal starter flow focuses on the clearer lifecycle triggers above.

Template fields such as {{firstName}}, {{churchName}}, {{amount}}, and {{donationType}} are filled from the run context plus your current church settings before any message is queued or sent.

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.

Live automations that include Delay steps also depend on the runner so those scheduled follow-up steps can resume later.

Automation processing sequence

Step-by-step explanation:

1. The first two arrows are the design stage. A ministry lead creates the automation, chooses the trigger, adds the steps, and activates it.
2. Later, a real branch event happens. That event could be a visitor submission, an invite link click, a new member record, or another supported trigger event.
3. Holy Resource does not send a message immediately when that trigger event appears. Instead, it queues the event for the Automation Runner to process.
4. The Automation Runner then checks which automations are active for that branch and which ones match the trigger that just came in.
5. Once the runner starts the matching automation, it walks through the workflow step by step. That includes evaluating conditions and respecting any configured delays.
6. If a workflow contains a delay, the runner waits until that time is reached. If it contains a condition, the runner decides which path to take based on the data available for that person or event.
7. When the runner reaches an SMS or email step, it does not send the message directly to the outside world. It hands that work to the communication outbox.
8. The outbox is the delivery layer. It sends the message through the configured email or SMS provider and helps keep the sending process, retries, and delivery history organized.
9. After those actions are processed, Holy Resource stores the run history, step results, and any failures so staff can review what happened later.

In plain language, the important idea is that automations are not magic background messages that fire the moment a trigger exists. They move through a controlled pipeline: trigger event, runner evaluation, outbox delivery, then execution history. That is why the Automation Runner and the outbox both matter so much operationally.

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

4) Flow Map toolbox (left side)

The Flow Map toolbox is where you add new blocks.

Rules:

• If/Else: check a rule and branch to Yes/No paths. For example, if a contact has a phone number, send SMS; otherwise, skip to email.
• Split Path: split traffic by percentage. For example, you can send 10% of people down one path and 90% down another to test different messaging or timing.
• Wait: pause until a resume condition is met. For example, wait until a contact submits a form or clicks a link.
• Time delay: wait a fixed amount of time. For example, wait 3 days before sending a follow-up message.

Actions:

• Send email: queue an email message using run data. For example, send a welcome email to a new subscriber.
• Send SMS: queue a text message using run data. For example, send a reminder SMS for an upcoming event.
• Webhook: post run data to an external endpoint. For example, notify an external system of a new lead.
• Tag/Untag: add or remove tags for downstream logic. For example, tag a contact as "VIP" after a purchase.
• Update contact: update contact fields for later steps. For example, update the contact's subscription status.

You can click a block to add it, or drag it onto the canvas.

5) AI Automator (optional assistant)

Builder now includes AI Automator to help teams draft automation flow structure faster.

Use it when you want to:

• Turn a plain-language prompt into a starter workflow graph.
• Suggest conditions, delays, and message actions from your intent.
• Attach supporting files (for example, process notes or spreadsheets) so the assistant has better context.

Important usage notes:

• AI Automator is an assistant, not an autopilot. Always review node settings before saving or activating.
• Start with Preview or Test mode after AI-generated changes.
• Keep final branch ownership and approval with your ministry lead or operator.

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

Run history management:

• You can bulk-select and delete test runs from the Runs tab.
• Live runs and currently active runs are protected from bulk deletion.
• Run artifacts used for test history stay local to the device and are not synced to other devices.

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.