How rules are evaluated

A Workflow (an automation) decides what happens to a comment. Only one Workflow ever acts on a given comment: the highest-priority Workflow that matches. Lower-priority Workflows that also match are suppressed. If a Workflow you expected to fire did not, another Workflow with higher priority almost certainly matched first.

This page explains the exact order the engine uses, so you can predict which Workflow wins.

The lifecycle of a comment

Every comment moves through the same four stages:

1. Received — the comment is ingested from the platform and written to your interaction history with a status of “pending”.
2. Evaluated — the engine tests it against your Workflows and picks exactly one winning branch (or none).
3. Action — the winning branch’s actions are carried out on the platform (for example, the comment is hidden or a reply is posted).
4. Logged — an audit record is written showing which Workflow and action fired. You can review this in the Audit Log (Analytics → Audit Log).

Received comments are pulled in two ways: real-time platform webhooks (the fast path) and a periodic poll that backfills anything the webhook missed. The poll runs on an interval of roughly 5 minutes for non-webhook sources such as ad comments.

Timing: how fast is “real-time”?

Moderation is near-real-time, measured in seconds — not instant, and not a long batch.

• Evaluation runs on a dedicated loop that wakes about once per second when there is a backlog.
• Execution (the actual hide, reply, or delete on the platform) runs on a separate loop that ticks about every 10 seconds.

So a comment that arrives by webhook is typically evaluated within ~1 second and acted on the platform within ~10 seconds after that. Failed platform actions are retried with exponential backoff (starting at 5 seconds, capped at 10 minutes).

Comments from ads or backfill are slower

Comments that arrive through the poll rather than a webhook can take up to about 5 minutes to be picked up before the ~1s / ~10s evaluation and execution timings apply.

Evaluation order and precedence

Three ordering rules stack, from outermost to innermost. Read them in this order to work out what will happen to any comment.

1. Across Workflows: first match wins

Your Workflows are ordered by priority (highest first). Workflows with equal priority are broken by creation time, newest first. The engine walks Workflows in that order and stops at the first Workflow that both:

• is in scope for the comment (see Scoping), and
• has at least one matching branch.

That Workflow fires. Every lower-priority Workflow is skipped, even if it would also have matched.

Observe-only Workflows still win

A higher-priority Workflow set to observe-only (it simulates actions instead of performing them) still counts as the winner and still suppresses lower-priority Workflows. Its actions are simulated and written to the log, but no lower Workflow gets a turn. If a live Workflow is not firing, check whether an observe-only Workflow above it is matching first.

2. Within a Workflow: first matching branch wins

A Workflow is a list of branches (each branch is a set of conditions plus the actions to run when they match). Branches are tried top to bottom. The first branch whose conditions match ends the search — later branches in the same Workflow are not evaluated.

3. Within a branch: all conditions must match

A branch’s conditions (the tests a comment must pass) are combined with AND. Every condition in the branch must match for the branch to match.

A branch with no conditions always matches — it is a catch-all. Put catch-all branches last, or they will swallow every comment before more specific branches below them get a chance.

A clean match

Here a single Workflow with one branch matches a comment and hides it.

Input comment

giveaway_bot Facebook

🎉 FREE giveaway! Check my page to claim your prize now!!!

↓

Matched condition

Keywords: "free", "giveaway" (match any)

↓

Resulting action Flag

Keyword matching is case-insensitive and matches partial text (substring), so 'FREE' matches 'free'. Flag hides the comment on-platform and sends you a push notification. It is reversible — an Allow action or a human approval un-hides it.

Flag hides the comment; Delete does not work on Meta

Flag is not a passive label — on Facebook and Instagram it hides the comment on the platform and sends a push notification. The separate Delete action permanently removes a comment and cannot be undone, but Delete is not supported on Facebook or Instagram — a Delete action on a Meta comment is a no-op. Use Flag to take a comment down on Meta.

Why didn’t this fire? A precedence case

The most common “my rule didn’t fire” report is a lower-priority Workflow being suppressed by a higher-priority one that matched first.

Say you have two Workflows:

• “Hide spam” — higher priority. One branch, condition Keywords: "free" (match any), action Flag.
• “Reply to fans” — lower priority. One branch, condition Keywords: "love" (match any), action Reply.

Now a comment arrives that contains both words:

Input comment

a_real_fan Instagram

I love this — free shipping made my day!

↓

Matched condition

"Hide spam" matched first on Keywords: "free". "Reply to fans" was suppressed.

↓

Resulting action Flag

Both Workflows would have matched this comment. Because 'Hide spam' has higher priority, it wins and fires its Flag action. 'Reply to fans' never runs — no Reply is posted. To make the friendly reply win here, raise 'Reply to fans' above 'Hide spam', or narrow the 'Hide spam' condition so it doesn't match this comment.

Symptom: a Workflow that clearly matches a comment produces no action.

Cause: a higher-priority Workflow (possibly observe-only) matched the same comment first and suppressed it.

Fix: reorder your Workflows so the one you want to win sits higher, or tighten the higher Workflow’s conditions so it stops matching the comments you want the lower one to handle.

Prevention: keep broad catch-all Workflows and branches at the bottom, and use Testing workflows to preview which branches match before you rely on a Workflow in production.

Human moderation is never overwritten

If a comment was already moderated by a person, a Workflow will still record an audit row but will not change the human decision. Manual moderation always takes precedence over automation.

Scoping: where a Workflow applies

A Workflow only sees comments inside its scope. Scope is layered:

• Workspace — the primary boundary. A Workflow evaluates comments in its own workspace only.
• Page (optional) — if a Workflow is scoped to a specific page, it only matches comments from that page. Unscoped, it matches every page in the workspace.
• Source type (optional) — a Workflow can be limited to certain source types, such as organic or ad. Comments default to organic.

Effective scope is workspace × optional(page) × optional(source type). A comment that falls outside a Workflow’s scope is not a “no match” — the Workflow is skipped entirely for that comment, and the engine moves to the next Workflow.

Scope gates run before conditions

Because scope is checked before a Workflow’s branches, a scope mismatch is a frequent hidden cause of “why didn’t it fire.” Confirm the Workflow is scoped to the right page and source type before debugging conditions.

Related

• Conditions — the four condition types and exactly how each one matches.
• Actions — what Flag, Allow, Reply, Delete, and the rest do on the platform.
• Testing workflows — preview which branches match before going live.
• What happens while disconnected — how moderation pauses and backfills when an account’s connection drops.