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.
Start simple and scale as you go
If you are implementing Gladly Team for the first time, especially if you are migrating from a ticket-based system, resist the urge to recreate all of your existing Rules in Gladly Team on day one.
The conversational model works fundamentally differently from ticket-based systems. Many rules that were necessary in your previous system may not be needed in Gladly Team. Over-engineering your Rules during implementation can lead to unexpected behavior, contradictory logic, and unnecessary complexity.
Start with the essentials:
Spam filtering
Basic Inbox routing
Auto-replies on first message
Agent Away/Offline handling
Core Topic application
Go live with this minimum set, let your team experience the conversational model for a few weeks, and then refine. Once your team understands how Gladly routes and manages Conversations, you can layer in more advanced Rules, URL-based chat routing, Estimated Wait Time messaging, automatic Task creation from Topics, and more.
A simple workflow may need 15–20 Rules. Complex organizations can have 150 or more. Some large-scale implementations run over 400 Rules. That complexity should be built iteratively, not all at once.
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.
Due date Triggers evaluate at the exact threshold, not before or after. If you configure a Rule with Conversation due date is Due in 120 minutes, the Rule fires at the precise moment the Conversation reaches 120 minutes before the due date. If the Conversation is already at 119 minutes before the due date when the Rule is activated, the Rule will not fire on that Conversation; the threshold has already passed.
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
Underused Condition: URL-Based Chat Routing
The URL Condition is one of the most powerful and underutilized Conditions available for Chat. It allows you to route Conversations based on the URL of the page where the Customer initiated the chat.
This means you can route Conversations differently depending on where the Customer is on your website:
A chat started on your FAQ page could route to a general support Inbox.
A chat started on a product page could route to a product specialist or sales Inbox.
A chat started on a high-value product page (e.g., a page featuring premium or luxury items) could route to Agents with the highest conversion rate.
Most organizations do not implement URL-based routing at launch because CX teams often lack visibility into where Customers initiate chats. However, this is an excellent optimization to revisit after your team has been live on Gladly for a few months and has a better understanding of Customer behavior on your site.
To use this Condition, select URL from the Conditions list, then specify whether the URL contains or does not contain specific text using Any, Only, RegEx, or Words matching.
Note that the URL Condition does not support comma-separated values. If you need to match multiple URLs, create a separate Rule for each.
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.
When to Use Rules vs. Gladly AI
Rules and Gladly AI serve different purposes and operate independently. Understanding when to use each will help you avoid duplication and build more effective workflows.
Use Rules for | Use Gladly AI for |
|---|---|
Deterministic automation based on specific keywords, Channels, or Customer attributes | Intent classification and conversational responses |
Routing Conversations to Inboxes based on known criteria | Understanding what a Customer is asking and resolving it autonomously |
Sending auto-replies | Generating dynamic, contextual replies |
Closing spam or abusive Conversations based on keywords | Detecting spam via AI-based email spam flagging |
Applying Topics based on keywords or Answers used | Applying Topics based on inferred intent |
Creating Tasks based on specific Triggers | Guiding Customers through multi-step resolution flows |
Rules do not fire on Conversations handled by Gladly AI until the Conversation is handed off to a human Agent. This is a critical distinction. If a Conversation is being managed by Gladly AI, none of your Rules, including auto-replies, keyword routing, Topic application, or spam closing, will execute until handoff occurs.
When evaluating whether a workflow should be handled by a Rule or by Gladly AI, ask: Is the logic deterministic and condition-based, or does it require understanding the Customer's intent? If it is deterministic, use a Rule. If it requires intent detection, use Gladly AI.
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.