Front Rules Explained (2026): The Automation Engine

The When / If / Then model

Every Front rule, no matter how elaborate, is the same three-part sentence. Per Front's guide to rule triggers, conditions, and actions, a rule is built from a trigger (When), one or more conditions (If), and one or more actions (Then).

The trigger is the event that wakes the rule up. Common ones are an inbound message is received, a conversation is assigned, a tag is added, a comment is posted, or a conversation is archived or reopened. Nothing happens until a trigger fires — a rule is asleep until its event occurs.

The condition is the test the conversation has to pass. This is where you narrow things down: subject contains "invoice", the from field is from a specific domain, the conversation is in a chosen inbox, a particular tag is present, or it's outside business hours. Conditions can be chained with AND/OR logic, so you can require several things at once or accept any of a set.

The action is what Front does when the trigger fires and the conditions pass: add a tag, assign to a teammate (with round-robin or load balancing), move to another inbox, reply with a template, create a shared draft, archive, or send to Slack or a webhook. You can stack multiple actions in a single rule.

That linear shape — one trigger, some conditions, some actions — is what Front calls a linear rule, and it covers the overwhelming majority of automations a support, sales, or ops team needs. (Front also offers branching smart rules for multi-step logic, but the WHEN → IF → THEN sentence is the foundation underneath both.)

Company vs workspace vs individual rules

The same rule can live in one of three scopes, and the scope decides who it affects and who can edit it. Front documents all three in Understanding rules.

Individual rules apply only to your personal inbox. You create them yourself under Personal settings → Rules, and nobody else sees them. These are the productivity tweaks — auto-tagging your own newsletters, snoozing certain senders — and, usefully, they don't count against your plan's rule limits.

Workspace rules (often called shared rules) apply to your team's shared inboxes. They're created by workspace or company admins under Workspace settings → Rules and macros, and they're the workhorse: the routing, tagging, and assignment logic the whole team depends on. Because they touch shared work, only admins can change them.

Company rules apply across all individual and/or shared inboxes at once and can only be created by company admins, under the Company settings tab. They exist to centralise logic you'd otherwise have to duplicate everywhere — a company-wide tagging or compliance rule you don't want to maintain in twenty places. Company rules are an Enterprise-plan feature.

Rule order and "stop processing other rules"

When several rules could act on the same conversation, order decides who goes first — and one switch decides whether anyone else gets a turn at all.

Company rules always win the priority contest. Front is explicit: company rules "will always have priority over individual or workspace rules and behave as if they were ordered before all other rules." They run first, every time, regardless of list position.

Within a scope, you set the order yourself. In the rule list, admins type a rule's desired position or use the arrows to move it up and down. Rules are evaluated top to bottom, so the more specific, higher-stakes rules generally belong nearer the top.

That order matters most because of one checkbox: Stop processing other rules. When you enable it on a rule, Front runs that rule's actions and then stops — subsequent rules are ignored even if they would have matched the same conversation. It's how you say "this case is handled, don't let anything else touch it." Because company rules run first, a company rule with stop processing enabled can silently prevent every downstream workspace and individual rule from firing — a genuinely useful lever, and a genuinely easy way to wonder why a rule you built "isn't working."

There's one deliberate exception. Delayed rules — those built on time-based conditions like Unreplied after, Unassigned after, or Time since triggered — bypass the stop-processing setting, because they're scheduled to run later rather than in the immediate evaluation pass.

Why a rule can't trigger itself

This is the behaviour that confuses almost everyone at least once. You build a rule whose action would satisfy its own trigger — say, a rule triggered by tag added whose action is to add another tag — and you expect a cascade. It doesn't happen.

Front's engine is sequential, and by design a rule cannot trigger itself. This prevents the obvious infinite loop: a rule that fires, performs an action, that action re-fires the same rule, forever. The same principle is why company rules cannot be triggered by workspace rules — since company rules always execute first in the pass, a later workspace rule's actions can't loop back and re-run them.

The practical upshot: if you need a chain — rule A's action should cause rule B to run — those have to be different rules, ordered so B evaluates after A in the same pass, and A must not have stop processing enabled. If you find an automation mysteriously not cascading, this self-trigger prevention is very often the reason.

The honest limits — and where an AI layer picks up

Front's rule engine is deterministic and dependable, which is exactly its virtue. It does precisely what you tell it, in a predictable order, every time — and for routing, tagging, assignment, and templated auto-replies, that determinism is what you want.

But notice the ceiling. Rules match on patterns, not meaning. A condition like subject contains "refund" is a keyword match; it doesn't understand that "I was double-charged and want my money back" is also a refund. It can route a billing question to the billing inbox, but it can't read the question, check the customer's actual invoice, and write the answer. A template reply is the same fixed text for everyone who trips the trigger — it can't tailor a response to this customer's situation.

There's plan friction, too, and it's fair to name it: workspace rules are capped by plan — roughly 10 on Starter and 20 on Professional, with Enterprise unlimited — while the most powerful actions (load balancing, dynamic variables, webhooks, and company rules themselves) sit behind Professional or Enterprise tiers. On a smaller plan, a busy team can hit the rule ceiling faster than expected. Front's pricing tiers lay out exactly what unlocks where.

This is the seam where an AI agent layer fits — not to replace the rule engine, but to do the reasoning-heavy part it structurally can't. The broader category of AI agents for customer service exists precisely for the work a keyword match can't do. Macha is one such layer: it runs on top of the Front you already use through the live Macha–Front connector — it does not replace Front, your shared inboxes, or your rules. You keep your rules doing what they're good at: getting the right conversation to the right place with the right tags. Then Macha's agent reads that conversation, understands intent rather than keywords, and drafts or sends a grounded reply — pulling a real order or account status through a custom tool that turns your REST API into something the agent can call. A rule tags a message "billing" in milliseconds; an agent then actually resolves the billing question. If you want the mechanics, connecting Front to Macha to route conversations to AI walks through it, and Macha's credits are consumed per AI action, never per resolution — automation and reasoning have different costs, and it's honest to price them that way.

The clean division of labour: let Front rules be the deterministic dispatcher, and layer an agent on top for the part a pattern-match can't do — reading the conversation and answering it well. For how rules and tags work together as a system, see Front tags explained and the wider Front shared inbox model.

FAQ

Where do I create rules in Front? It depends on scope. Individual rules live under Personal settings → Rules, workspace (shared) rules under Workspace settings → Rules and macros, and company rules under the Company settings → Rules tab (admin-only, Enterprise). Each rule is built as a When (trigger) → If (condition) → Then (action) sentence.

What's the difference between company, workspace, and individual rules? Individual rules affect only your personal inbox and are exempt from plan limits. Workspace rules affect a team's shared inboxes and are admin-created. Company rules apply across all inboxes company-wide, can only be made by company admins, and are an Enterprise feature. Company rules always execute first.

What does "stop processing other rules" do? When enabled on a rule, Front runs that rule's actions and then stops — any subsequent rules that would have matched the same conversation are skipped. Delayed, time-based rules (Unreplied after, Unassigned after, Time since triggered) are the exception and bypass this setting.

Why won't my Front rule trigger another rule? Front's rule engine is sequential and a rule cannot trigger itself, which prevents infinite loops. For the same reason, company rules can't be triggered by workspace rules. To chain automations, use separate rules ordered so the second evaluates after the first, and make sure the first doesn't have "stop processing other rules" enabled.

Can I add AI to Front rules without replacing Front? Yes. An AI agent layer like Macha connects to Front as a live connector and runs on top of your existing inboxes and rules — it doesn't replace them. Your rules keep routing and tagging deterministically; the agent reads the routed conversation, understands intent, and drafts or sends a grounded reply.

Ready to turn "routed and tagged" into "actually answered"? Start a free trial of Macha and connect it to your Front in minutes.