Gorgias Rules Not Triggering (or Firing on Wrong Tickets): Fixes

Symptom → likely cause, at a glance

Start here, then jump to the numbered fix that matches.

The common causes, in order

1. The rule is disabled — check the enabled toggle first

The most common and most embarrassing cause. Under Workflows → Tools → Rules, every rule has an enabled/disabled toggle right on the list view. A rule can be perfectly conditioned and simply switched off. This is exactly what the Rules list is for — it's the debugging view, showing each rule's on/off state and last-updated date at a glance.

2. You're on the wrong trigger

Gorgias rules fire on one of a fixed set of triggers, and picking the wrong one is a silent failure. Per the Gorgias Rules FAQs, the available triggers are Ticket Created, New Message In Ticket, Ticket Updated, Ticket Assigned To User, and Ticket Snooze Delay Ends — and that's the whole list. A rule set to Ticket Created fires only once, when the first message arrives; if you expected it to react to a customer's follow-up, you needed New Message In Ticket. And note there is no native time-based trigger — if you want a rule to run after a delay, you have to route it through the snooze mechanism and fire on Ticket Snooze Delay Ends.

3. Rule order — the wrong rule is winning

If a rule runs but the wrong one takes effect, order is almost always the answer. Rules execute by trigger first, then by list position: Ticket Created rules run before New Message In Ticket, which run before Ticket Updated, then Ticket Assigned. Within a single trigger, they fire "in the order listed on the Rule settings page, from top to bottom." So if a broad "assign everything to the general queue" rule sits above your specific "VIP → priority" rule, the broad one can act first and set state your later rule then reads incorrectly. Drag specific rules above generic ones, and keep destructive rules (auto-close, spam) where they belong in the sequence. For the fuller mental model of how triggers and ordering interact, see Gorgias rules explained.

4. Case-sensitive tags and IS / IS NOT

This is the classic "works on some tickets, not others" trap, and it's a documented behavior, not a bug. Two things to know:

• The IS and IS NOT operators are case-sensitive. Other operators (contains, etc.) are not. So a rule condition using IS against refund will not match a value of Refund.
• Tags are case-sensitive. Auto-Reply and auto-reply are two different tags in Gorgias. If a rule is meant to match — or apply — a tag, the capitalization has to be identical to the tag that actually exists on your tickets. A rule that applies VIP and a downstream rule that looks for vip will never see each other.

When a rule fires inconsistently across otherwise-identical tickets, audit the exact casing of every tag and every IS/IS NOT value before touching anything else.

5. Nested IF / ELSE — the branch you expected was skipped

Gorgias rules support IF / AND / OR / ELSE logic, and the most common confusion is expecting both branches to run. They don't. Per the rule builder conditions docs, when the IF conditions are met, the ELSE branch is ignored; the rule only "moves on to the ELSE branch" when the IF conditions are not met. If you built a rule expecting the ELSE action to also apply, that's why it's "skipped" — by design, exactly one branch runs per evaluation. Restructure into separate conditions (or separate rules) if you genuinely need both paths to fire.

6. Multiple Shopify stores — the multi-store customer trap

This one is pure ecommerce and it surprises almost everyone. If you have more than one Shopify store connected to Gorgias, and a customer has profile data or orders in more than one of those stores, Shopify-dependent rules break. Specifically, the Rules FAQs note that some Shopify actions will fail for such a customer, and — critically — if your rule uses a condition that references Shopify data (like Shopify Customer or Shopify Last Order) and the customer has an order in more than one integrated store, the rule won't be executed at all. So a WISMO auto-tag or an order-status routing rule can silently no-op for exactly your best cross-store shoppers. If a Shopify-conditioned rule works for most customers but mysteriously skips some, check whether those customers exist in multiple connected stores. (This only reproduces on an account with two or more Shopify stores actually connected — a single-store or trial account won't show it.)

7. G Suite Groups — auto-replies that skip certain inboxes

If an auto-reply rule triggers on some email tickets but not others, check the address that received the customer's message. Gorgias does not send auto-replies to cc_recipients when the preceding message carries a header hinting at a mailing list — which is exactly what G Suite (Google) Group addresses produce. So mail that arrives via a group alias can legitimately skip your auto-reply rule. Related: Gorgias also rate-limits auto-replies to no more than once per 5 minutes per customer, so a rapid back-and-forth won't fire a fresh auto-reply each time.

8. Macros with Shopify or HTTP actions won't run from a rule

A subtle but well-documented gotcha: macros that contain Shopify, Recharge, Webhook, or HTTP-hook actions are not usable in Rules. If you're building a rule that applies a macro and the macro you want doesn't appear as an option — or attaches but the external action never fires — this is why. Those action types are excluded from rule-applied macros. The workaround is to split the macro: keep the text/tagging portion in the rule-safe macro, and handle the Shopify/HTTP side through a dedicated integration action or a purpose-built tool. For how macros are meant to be composed, see Gorgias macros explained.

9. You're near the rule ceiling

Gorgias caps accounts at 70 rules, with a warning surfacing around 65. If you're at the ceiling, newly created rules may not behave as expected. Prune stale or duplicate rules — this is also a good moment to consolidate the sprawling keyword-and-tag rules that tend to accumulate. For building the ones you keep the right way from the start, our step-by-step on how to set up rules in Gorgias covers the setup path.

The honest limit of a rules engine

None of the above is Gorgias's fault — the engine is deterministic and, once you understand triggers and ordering, entirely diagnosable. A rule either matched or it didn't. But that determinism is also the ceiling. Rules match on exact tags, exact casing, and fixed Shopify fields; they cannot understand that "I was charged twice and want it back" and "please refund my order" mean the same thing. So teams paper over the gap with ever-longer tag lists and case-matched conditions — and those lists are precisely what quietly break when a tag's capitalization drifts or a customer turns up in a second Shopify store. When your rules keep "not triggering" because real customer language keeps escaping your conditions, you've hit the edge of what a rules engine can express, not a setting you missed.

Where an AI layer picks up

This is the seam where an AI agent layer for customer service helps — and it's worth being clear-eyed and honest about it. Macha is one such layer. It runs on top of the Gorgias you already use — it is not a help desk and does not replace Gorgias. It connects to Gorgias and reads and writes the same tickets your rules touch (replies, tags, status, assignment), matching on intent rather than exact tags and casing, so "refund me" and "I was double-charged" route the same way without a hand-maintained, case-sensitive tag list. It doesn't fight your deterministic rules — it takes over the intent-heavy reasoning those rules were never built for, while your routing and auto-close rules keep doing what they're good at.

Because an agent acts on meaning rather than a fixed condition, you can grade it before it touches a live queue, and extend what it does with a custom tool that turns any REST API into an action the agent can call — looking up an order across your stores mid-conversation, something no native Shopify condition can do cleanly across multiple stores. For a walkthrough of putting one on your queue, see how to connect Gorgias to Macha and automate ticket replies, or check pricing — credits are charged per AI action, not per resolution.

FAQ

Why is my Gorgias rule not triggering even though the conditions look right? Check, in order: is the rule enabled (the toggle on the Rules list), is it on the right trigger (Ticket Created fires once; use New Message In Ticket for follow-ups), and does every tag and IS/IS NOT value match the exact casing on the ticket? Tags and the IS/IS NOT operators are case-sensitive, so Refund and refund are different values.

Why does my rule fire on the wrong ticket? Almost always rule order. Rules run by trigger (Ticket Created → New Message In Ticket → Ticket Updated → Ticket Assigned), then top-to-bottom within each trigger. A broad rule sitting above your specific one can act first and change state your later rule reads. Reorder so specific rules sit above generic ones.

Why doesn't my Shopify-based rule run for some customers? If you have multiple Shopify stores connected and a customer has orders or profile data in more than one of them, rules that reference Shopify data (like Shopify Last Order) won't execute, and some Shopify actions fail. It's a documented multi-store limitation, not a broken rule.

Why can't I add my macro to a rule? Macros that contain Shopify, Recharge, Webhook, or HTTP actions aren't usable in Rules and won't appear as an option. Split the macro: keep the text/tag part rule-safe and handle the external action separately.

Can an AI agent replace these fragile rules? Often, yes — when the real problem is that customer wording keeps escaping your exact-match, case-sensitive conditions. An AI layer like Macha connects to Gorgias and matches on intent rather than tags, running on top of your existing rules rather than replacing them. See the Gorgias integration and pricing for details.

Ready to stop losing tickets to conditions that can't read? Start a free trial and grade a Macha agent against your own Gorgias history before it goes live.