This guide covers best practices for creating, organizing, and auditing Rules in Gladly, drawn from common patterns seen across Customer implementations.
How to get started with Rules
Every Rule has three required components:
Trigger -- The event that kicks off the Rule (one per Rule)
Conditions -- The criteria that must be met (all Conditions are AND logic)
Actions -- What Gladly does when the Trigger and Conditions are satisfied
Gladly will not validate the logic you put into a Rule -- it only checks that all three components are present. This makes planning critical before you build.
Before you build: Define the business goal
Before creating any Rule, ask yourself: What is the business goal I'm trying to achieve?
Write it down. If you cannot tie the Rule to a clear business outcome, think twice about creating it. This written goal becomes your guide for constructing the Trigger, Conditions, and Actions -- and it becomes the benchmark for whether the Rule should remain active during future audits.
Quick reference checklist
Use this checklist to help you ensure you are creating Rules using best practices described in this help doc.
Every Rule has a clear business goal documented
Rules are named descriptively
Spam Rules are at the top of the sort order
Rules are ordered most restrictive to least restrictive
Text-matching Rules use "Words" where possible
Only one text-match Condition per Rule (not subject AND body)
Auto reply Rules include "message initiates a conversation"
"No Reply Needed" is always paired with "Close Conversation"
Agent Away/Offline Rules are in place
New Rules are moved to the correct sort position (not left at the bottom)
Rules are audited at least quarterly
Naming conventions
Approach your Gladly admin setup as if you're handing it off tomorrow. Name every Rule descriptively enough that someone unfamiliar with your setup can understand what it does without clicking into it.
Avoid generic names like "Email Rule 1" or "New Rule"
Include the purpose in the name (e.g., "Email - Route Returns to Returns Inbox" or "Spam - Close & Tag Spam Emails from Subject")
You can rename Rules at any time -- go back and rename vague ones
Rule Sort Order (critical)
How Sort Order works
Rules execute from top to bottom based on their position in the Rules list. The Rule with sort order "1" is evaluated first. You can change sort order by dragging and dropping Rules in the interface or editing the sort order field directly.
Key behaviors:
Duplicate Rules are ignored – if two Rules would do the same thing, the one with higher priority (closer to 1) fires
Once a conversation is closed by a Rule, subsequent Rules will not apply to that conversation
Inbox assignment only happens once – if a Rule higher in the list assigns an inbox, a lower Rule doing the same will not override it
How to approach sorting
Think of your Rules list like peeling layers off an onion:
Put spam Rules at the top. Clear out junk first so the rest of your Rules can process clean conversations.
Order remaining Rules from most restrictive to least restrictive. Rules with more specific Conditions should come first; broader catch-all Rules should be lower.
Group Rules that do similar things together (e.g., all inbox-routing Rules in one block, all auto-reply Rules in another).
The most common mistale
Creating a new Rule, clicking save, and leaving it at the bottom of the list. That Rule may never fire if a less-restrictive Rule above it already handles the conversation. Always move new Rules to the correct position after saving.
Sort Order example
Sort Order | Rule | Why This Position |
|---|---|---|
1 | Spam - Subject Contains Spam Words | Clears junk first |
2 | Spam - Body Contains Spam Words | Second spam layer |
3 | Email - Route VIP to VIP Inbox | Most restrictive routing |
4 | Email - Route Returns to Returns Inbox | Specific keyword routing |
5 | Email - Route General to Default Inbox | Catch-all (least restrictive) |
Triggers: Key Guidance
Each Rule gets one Trigger only. The most common Triggers and how to use them:
Communication received
The most common Trigger. Fires when any message comes in (email, chat, SMS, etc.).
Conversation due date
Used for SLA-based workflows. You must specify: due in X minutes, exactly overdue, or overdue by X minutes.
Topic added (Underused)
A powerful Trigger that most Customers overlook. When a topic is added to a conversation, you can automatically create tasks, move conversations to inboxes, or take other Actions. If your organization uses topics heavily, build Rules around this Trigger.
Answer used (Underused)
When an agent clicks "Use" on an answer to respond to a Customer, this can Trigger a Rule. Great for automatically applying topics based on the answer used -- saving agents manual steps. At scale (e.g., 100,000 conversations/year at 2 seconds per manual topic application), this can save 50+ hours annually.
Agent status changes
Fires when an agent goes Away or Offline. Essential for ensuring Customers are not stuck with an unavailable agent.
Conditions: common pitfalls
All Conditions are AND logic
Every Condition in a Rule must be met for the Rule to fire. If you need OR logic, build separate Rules.
Avoid multiple text matches in one Rule
Do not put both "message subject contains X" and "message body contains X" as Conditions in the same Rule. Since both must be true (AND logic), the word must appear in both the subject and body -- which rarely happens. Instead, create two separate Rules: one for subject, one for body.
"Any" vs. "Words" vs. "Only" for Text Matching
Operator | Behavior | Best For |
|---|---|---|
Words | Matches exact whole words; supports multiple comma-separated phrases | Most use cases -- start here |
Any | Matches partial strings (e.g., "change" matches "exchange") | Broad matching when you need variations |
Only | Matches a single phrase exactly | Very restrictive single-phrase matching |
Best practice
Start with "Words." It gives you the most control and avoids false positives. If you have older Rules using "Any," review them -- you may be catching unintended matches (e.g., acronyms in URLs or signatures Triggering spam Rules).
Chat Rules cannot use Message To/From
Chat inherently does not have message-to or message-from fields. If your chat Rules use these Conditions, they will never fire.
Actions: Best Practices
Assign to Inbox (common)
Route conversations to the right inbox based on keywords, Channels, or Customer attributes. This is the core use case for most Rules.
Assign to Agent (use sparingly)
Assigning directly to an agent bypasses Gladly's routing engine. Only use this when a single specific person must handle a type of issue. In most cases, assign to an inbox and let routing handle agent assignment.
Unassign from Agent
Removes the agent but keeps the conversation in the same inbox, making it available for the next agent. Essential for handling agent Away/Offline scenarios.
Add Topics (use frequently)
Automate topic application wherever possible. This saves agent time and improves reporting accuracy.
Send auto reply
Always pair with "message initiates a conversation" as a Condition. Without it, the Customer gets an auto reply on every message in the thread.
Consider building multiple targeted auto replies based on reason for contact rather than one generic reply for everything.
Auto replies sent by Gladly do not affect the SLA of the incoming communication.
Mark as 'No Reply Needed'
This clears the SLA on all outstanding contacts in the conversation, not just the latest one
Always pair with Close Conversation to avoid conversations stuck in a waiting/limbo state that never appear in reports
Without closing, you can end up with thousands of invisible conversations
Create Task
Automate task creation based on topics or keywords. This is especially useful for follow-up scenarios (e.g., warehouse research, returns processing). Set the due time in minutes within the Rule to avoid the default 30-minute due time that agents would otherwise need to manually adjust.
Things Rules cannot do
Prioritize Channels – Gladly has a fixed Channel hierarchy (Phone > Chat > SMS > Social DM > Email > Voicemail > Tasks). Rules cannot change this.
Work reliably with phone calls – Phone calls go directly to the voice queue and route to the next available agent before Rules can execute. Do not build Rules around phone calls.
Change SLAs based on business hours – SLAs are always calendar-based. You can use business hours to Trigger different auto replies (e.g., after-hours SMS), but not to adjust SLA timing.
Delete inactive Rules c Inactive Rules are retained for historical reference. They show in the conversation timeline and provide an audit trail.
Auditing your Rules
When to audit
Make it a regular practice -- at minimum quarterly. If you have not looked at your Rules in the past month, schedule time now.
How to audit a Rule
For every Rule, ask:
What does this Rule do?
What is the business impact?
Is it still relevant?
If you cannot quantify the business impact, consider deactivating the Rule.
Track Rule effectiveness with Topics
When you create a new Rule that impacts a large number of Customers, add a "tracking topic" as an Action (e.g., an admin-only topic like "Rule-093-Fired"). Then use the Topics report to see how often that topic was applied over a few weeks. This tells you whether the Rule is actually firing and how often.
After you have enough data, you can remove the tracking topic or adjust the Rule based on results.
Preparing Rules in advance
You can create Rules and leave them inactive until you are ready to deploy. This is ideal for:
New product launches
New contact forms with different fields
Seasonal campaigns
Build and test the logic ahead of time, then activate when ready.
Core Rules every Gladly instance should have
At minimum, your Rules should cover:
Spam filtering – Separate Rules for email subject and email body, using the spam word list from connect.gladly.com
Inbox routing – At least one Rule per inbox to route conversations appropriately
Auto replies – Triggered only on first message; consider multiple replies based on contact reason
Agent Away/Offline handling – Two Rules: one for when agent status changes, one for when a communication is received while the agent is already offline
Topic application – Automate where possible using Answer Used or Communication Received Triggers
Task creation – For follow-up workflows that require Action outside the conversation
A simple workflow may need 15-20 Rules. Complex organizations may have 150+ Rules. Some large-scale implementations run over 1,000 Rules.