Overview

Rules let you say "when X happens on a conversation, do Y." Once you have a few rules in place, the platform starts doing routine work for you — assigning, labeling, creating tasks, sending templated messages, closing finished threads — without anyone touching a button.

This lesson covers the building blocks of a Conversation rule and a concrete example to make it tangible.

How a rule works

Every rule has three parts:

1. A trigger — what event the rule reacts to (for Conversations, this is typically "a new post arrived")
2. Conditions — checks that must be true for the rule to fire (e.g., sentiment is negative, OTA is Airbnb, intent is Complaint)
3. Actions — what happens when the conditions match (e.g., add a label, create a task, send a templated message, change status)

Rules evaluate every time a new event occurs. They are not retroactive — turning on a rule today won't process yesterday's conversations.

You'll find rule management in Rules in the main navigation. Conversation rules use the Conversation Post target type.

Note: Conversation Post rules fire only on inbound (guest-sent) posts. Replies from your team, Autopilot sends, and system messages from the channel do not trigger rules.

Conditions you can use

A non-exhaustive list of what you can match on:

Conditions are combined with AND by default. A rule with three conditions fires only when all three match.

Actions you can take

What rules can do on Conversations:

The exact set of available actions can grow over time and is influenced by which integrations you've connected.

Example rule worth setting up

Rules can automate almost anything. Here's one concrete pattern to make it tangible.

Auto-create tasks from detected cleaning or maintenance issues

When a new conversation post arrives AND has cleaning issues (or maintenance issues), create task in your task system.

Each detected issue becomes its own task — routed to the right team with the issue details pre-filled. You don't have to read every message to know something needs action; the rule handles it.

For the full mechanics of how task creation works (multi-issue enumeration, department mapping, duplicate prevention), see the Task Creation Guide.

The possibilities go well beyond task creation. Rules can assign conversations, apply labels, send templated messages, trigger webhooks, and more. The example above is a starting point — build the ones that fit your operation.

Common pitfalls

A few things teams trip over when building rules:

• Over-triggering. A rule that adds a label every time a post arrives will run thousands of times. Add a condition that narrows it.
• Conditions ANDed when you meant OR. Two conditions both required = fewer matches than you might expect. Build narrower rules and let multiple rules fire if you want OR-like behavior.
• Forgetting the rule is forward-only. A rule turned on today won't act on existing conversations. If you need to backfill, that's a manual or one-off operation, not a rule.
• Rule order matters less than you think. Most actions are independent. The exception is anything that creates duplicates (e.g., two rules that both create a task on the same issue) — be careful not to double up.

Testing a rule

Before turning a rule loose on a busy inbox, the safest pattern is:

1. Build the rule with the action set to "Add label" only (e.g., "would-fire")
2. Let it run for a day
3. Filter conversations by that label and confirm it fired on the right ones
4. Delete the test action and add the real ones
5. Turn the rule on for real

This is especially worth doing for rules that send messages, create tasks, or change status — the irreversible kind.

Up next

Autopilot: Auto-Reply Safely at Scale — the rules engine handles automation around conversations. Autopilot is the special case for the reply itself.

Related

• Task Creation in Sparrow Intel
• Rules & Automations collection