Automations

Automation Building Blocks: Triggers, Conditions, and Actions

Every Revamp365 automation is three parts in sequence: one trigger that starts it, an optional filter that decides which records continue, and one or more action steps that run in order. Open Automations in the left nav and click New automation — the builder walks you through Trigger, then Filter, then Step 1, Step 2, and so on.

The trigger: what starts the workflow

You pick exactly one trigger. Triggers are grouped by category in the picker:

• Contact — created, updated (watch specific fields), lead status changed, lead temperature changed, tag added/removed, list added/removed, imported, merged, assigned/reassigned, do-not-contact set, lead score threshold crossed.
• Deal — created, stage changed, field changed, closed won, closed lost, amount changed, archived.
• Call — voice AI call record created, completed, no answer, voicemail left, human call logged.
• SMS — inbound received, inbound keyword matched, sent, delivery failed, opt-out received.
• AI Agents — enrolled, replied, success, fallback, qualified/disqualified, paused/resumed, limit reached, stopped.
• Email — opened, clicked, bounced, replied, unsubscribed.
• Task / Note, Booking, Schedule / Time (recurring, contact-field date, business hours), Webhook, and Cross-automation (another automation completed, failed, or exited a branch).

Some triggers take config. "Inbound SMS keyword matched" asks for keywords and a match type (contains, exact, or starts_with). "Lead score threshold crossed" asks for a number and a direction (above/below) and fires only on the crossing, not while the score merely sits past the line.

The filter: conditions that gate enrollment

The filter is optional. When set, records that fail it are logged as filtered_out instead of running. Build conditions in the filter tree, combining them with AND, OR, and NOT groups. Each leaf compares a field to a value:

Fields can reference the contact, the deal, custom fields, or the trigger payload. Regex matching is also supported for text fields.

The actions: steps that run in order

Steps execute top to bottom by position. Available actions include sending SMS or email (template, AI-drafted, or from an assigned number), updating contact or deal fields, adding/removing tags and lists, creating tasks and notes, enrolling or pausing an AI SMS agent, starting a voice campaign or workflow, skip trace / Deep Trace enrichment, notifying a user, and calling a webhook.

Flow-control actions shape the path: Wait (delay by minutes/hours/days), Branch if (evaluate a filter tree and split), Switch, Random split, Wait for event, Exit automation, and enroll/unenroll in another automation.

Putting it together

1. Name the automation and choose a trigger.
2. Add filter conditions (or skip — the filter is optional).
3. Add action steps in the order they should run.
4. Set the enrollment policy: once per record, re_enroll every time, or cooldown (re-enroll only after a set number of minutes).
5. Toggle dry run to log what would happen without sending or writing anything, then save the automation.

New automations start as a draft. Activate one to move it to active; you can pause or archive it later. For a full walkthrough, see create your first automation, and check the run logs to see why a record was filtered out or a step failed.

Read Automation Run Logs and Fix Failed Runs

When an automation does not do what you expect, the Logs tab on the Automations page is where you diagnose it. Every enrollment and every step it ran is recorded with a status, timestamps, an error message, and the raw input/output, so you can see exactly which step failed and why.

Where the logs live

1. Open Integrations & Apps in the left navigation.
2. On the Automations card, click Open.
3. Click the Logs tab (next to Automations).
4. Use the toggle at the top right to switch between Enrollments and Step runs.

Enrollments is one row per contact or deal that entered an automation. Step runs is one row per individual action attempt. Click any row to open a detail dialog. The step-run detail shows Started, Completed, Attempts, the Error, and the full Input and Output JSON for that step.

You can also jump to a single automation's history: in the automations list, open the row's ⋯ menu and click Run history.

Run and step statuses

Enrollment status and step-run status use different vocabularies.

Failed and error rows are tinted red. filtered_out is normal — it means your filter conditions did their job.

Common failure causes

The Error column shows the raw reason. The most frequent ones:

• do_not_contact_block / opt_out_block — the contact is marked Do Not Contact or has texted STOP. See mark contacts DNC and understand STOP opt-outs.
• sms_quiet_hours_block — the send fell inside quiet hours and the step respects them.
• contact_missing / email_missing / from_phone_missing — the record has no linked contact, no email, or you have no active sending number.
• field_not_writable / custom_field_missing — an update step targets a field that does not exist or is read-only.
• engine_disabled — the automation engine is paused; the enrollment is set to delayed and retried on the next sweep.

Open the step run to read the full message and check the Input JSON to confirm the rendered values (phone, body, field name) were what you intended.

Use dry run to test safely

Dry run executes every step and records the outcome without firing real side effects — no SMS sent, no email delivered. In the builder, tick Dry run this automation (record outcomes without side effects), or set Dry run only on an individual step.

In dry-run step output you will see "sent": false and "dry_run": true. Run it against a real record, confirm the steps succeed and the input looks right, then turn dry run off to go live.

Fixing and re-running

1. Fix the root cause (clear the DNC flag, add a sending number, correct the field, or edit the step config in the builder).
2. Re-enter the record so the automation runs again from the failed step.

For a deeper walkthrough of triggers, conditions, and action settings, see automation triggers, conditions, and actions. To narrow a noisy log, use the Filter button to scope by automation, status, record, or date range, then save it as a view.

Create Your First Automation

Automations in Revamp365 run a sequence of actions automatically whenever an event fires on a contact or deal — for example, texting a lead the moment their status changes. Every automation is built from one trigger, optional filter conditions, and one or more action steps.

Open the automations builder

The builder lives on the Automations page (the engine is a paid feature on Pro+ and Dealmaker plans, and your phone number must be verified to reach it).

1. Go to Automations in the app. The page opens on the Automations tab, with a Logs tab beside it.
2. Click + Create automation in the top right. A full-screen builder opens titled "Create automation."
3. If you have no automations yet, the empty state also shows featured templates — click Use template on one to pre-fill the builder instead of starting blank.

Understand the trigger, condition, action model

The builder uses a left rail with three kinds of steps:

Build the automation

1. On the Trigger tab, enter an Automation name (for example, "Hot lead instant SMS").
2. Pick a Trigger event. Triggers are grouped by Contact, Deal, Call, SMS, AI Agents, Email, Booking, and Schedule / Time. Some triggers add their own settings — Inbound SMS keyword matched, for instance, asks for keywords and a match type.
3. Choose a Re-enrollment policy: Once per record (default), Every time the trigger fires, or Cooldown with a minimum wait in minutes.

1. (Optional) On the Filter tab, click Add filter to require conditions like lead_status equals Hot before the steps run. Leave it empty to run on every trigger match.

1. On Step 1, choose a Step type from the grouped action list (Communications, Contact data, Tasks / Notes / Tags / Lists, Deals, Flow control, AI Agents, and more), then fill in its fields. Message bodies support variables like {{ contact.first_name }}.

1. Click Add step to chain more actions. Use the Wait action under Flow control to space steps out. You can add up to 25 steps.
2. Click Save.

Tip: turn on Dry run on the Trigger tab to record what each step would do without actually sending — useful for testing before you go live.

Turn the automation on

New automations save as Draft, so nothing fires until you enable them.

• On the Automations list, flip the On / Off switch in the automation's row to activate it (its status changes to Active).
• Or use the row's actions menu and choose Activate.

Statuses are Draft, Active, Paused, and Archived. You can keep up to 50 automations active at once. To stop one temporarily, flip the switch off (it moves to Paused) without losing the configuration.

Once it is active, watch executions on the Logs tab. See read automation run logs and fix failures for how to read enrollments and step runs and retry failures.

Why the Automations Logs Tab Doesn't Show Everything That Ran

The Logs tab on the Automations page is scoped to one thing: automations. Workflows and SMS AI agents are separate engines and they do not appear there at all. That scoping is the single most common reason the logs look like they are lying to you.

What the Logs tab actually covers

1. Open Integrations & Apps in the left navigation.
2. On the Automations card, click Open.
3. Click the Logs tab.

You get two views, switched from the toggle at the top right:

• Enrollments — one row per contact or deal that entered an automation.
• Step runs — one row per individual action an automation attempted.

Every row on both views comes from an automation. Nothing else writes to this page.

What is missing from it

Three engines can send a text, update a field, or start a conversation, and only one of them is represented here:

Workflow enrollments, the individual texts a workflow sends, and AI agent conversations leave no rows on the Logs tab. Their record is the contact's timeline and the SMS thread itself.

The pattern that looks like a lie

Someone texts you. You open the Logs tab, and you see two rows at that exact second, both filtered_out, no steps run. Meanwhile you can see a real reply went out to that person at the same moment.

Both things are true. Two automations were offered the inbound text and correctly declined it, while a workflow — which does not log here — handed the thread to an AI agent and that agent replied. The empty-looking log is accurate for automations and silent about everything else.

The tell is on the contact's timeline, not on this page. See why so many timeline rows say System Automation.

What filtered_out means

filtered_out means the automation's audience filter did not match, so the record was never entered. It is not a failure and not an error, even though the status text repeats itself in the Error column of the same row.

Two things about that row read worse than they are:

• The Error column shows filtered_out again. That is the status restated, not a fault. Genuine failures show status failed with a real reason.
• The Steps column shows 0. In a Steps column a zero reads as "ran and did nothing". It means "never entered — skipped before step 1".

If you want to know why a filter did not match, open the automation in the builder, use Test on the Trigger step to pick that record, then open the Filter step and click Re-test filter. The result card there names the condition that failed and the value it saw. The Logs row does not carry that detail.

Where to look instead

The timeline is the only surface that merges all three engines into one feed, which makes it the right starting point whenever the question is "did something happen at all" rather than "what did this specific automation do".

Related: read automation run logs and fix failed runs, use the contact timeline, and hand a cadence reply to an SMS AI agent.