💡 Introduction
In one of our recent telecom client implementations, inbound email rules were one of the primary sources for case creation in ServiceNow. With six shared mailboxes, each routing to ServiceNow, we were handed a list of over 60 different 'From' and 'To' combinations - each expected to trigger specific default case values like assignment group, account, and contact.
The original approach? 60+ inbound email actions - one for nearly every rule.
The maintenance nightmare was obvious. When the client needed to update assignment group information, they couldn't even find the right inbound action among the dozens of similar configurations. That's when I took over the implementation.
I asked myself: can this logic live in a table instead of code?
🧩 The Original Setup
Let's walk through what I inherited:
- Six dedicated email mailboxes (e.g., emailbox1@gmail.com, emailbox2@xyz.com, etc.)
- Around 60+ 'From'/'To' address combinations, each with unique routing logic
- Implementation: 60+ separate inbound email actions — one per rule
Here's a sample of the actual conditions with their expected outputs (5 example rows out of 60+):I received one big file with all these details and formatted it for article purposes.
| No | Conditions | Expected Output |
| 1 | ('To' LIKE "emailbox1@gmail.com") AND (('From' LIKE "@abc.se") |
Assignment Group: Case Management Account Number: ACC123454 Contact Email: testing@abc.se |
| 2 | ('To' LIKE "emailbox1@gmail.com") AND (('From' LIKE "@def.se") OR ('From' LIKE "@def.com")) |
Assignment Group: Customer Support Account Number: ACC987654 Contact Email: help@def.se |
| 3 | ('To' LIKE "emailbox1@gmail.com") AND (('From' LIKE "@xyz.se") OR ('From' LIKE "@xyz.in") OR ('From' LIKE "@xyz.com")) |
Assignment Group: Technical Support Account Number: ACC456789 Contact Email: techsupport@xyz.se |
| 4 | ('To' LIKE "emailbox1@gmail.com") AND ('From' LIKE "@community.se" OR ('From' LIKE "@community.in")) |
Assignment Group: Community Relations Account Number: ACC321654 Contact Email: community@community.se |
| 5 | ('To' LIKE "emailbox1@gmail.com") AND ('From' LIKE "@community.com") AND ( 'Subject' starts with 'REQ')) |
Assignment Group: General Inquiries Account Number: ACC111222 Contact Email: NA |
🧠 My Optimization Strategy
Right away, I noticed something simple yet powerful:
- All logic was based on the 'To' and 'From' addresses
- The output was always a set of default case values: assignment group, account number, contact email, etc.
- This could be managed much more cleanly with Decision Tables
The client had provided an Excel file with all these conditions and expected field values - perfect input for Decision Tables.
🛠️ Step-by-Step Implementation
1. Decision Table Setup
For each mailbox, I created a dedicated Decision Table to handle the routing logic.
Decision Table Structure:
Input Fields:
- u_from - Email sender address
- u_subject - Email subject line
Output Fields:
- u_assignment_group - Target assignment group
- u_account_number - Account number to assign
- u_contact_email - Contact email to set
Sample Decision Table Rows: Here's how I converted the original conditions into Decision Table rows:
| From | Subject | Assignment Group | Account Number | Contact Email |
|---|---|---|---|---|
| @abc.se | * | Case Management | ACC123454 | testing@abc.se |
| @def.se | * | Customer Support | ACC987654 | help@def.se |
| @xyz.se | * | Technical Support | ACC456789 | techsupport@xyz.se |
| @xyz.in | * | Technical Support | ACC456789 | techsupport@xyz.se |
| @xyz.com | * | Technical Support | ACC456789 | techsupport@xyz.se |
| @community.se | * | Community Relations | ACC321654 | community@community.se |
| @community.in | REQ | General Inquiry | ACC321654 | community@community.se |
Note: For complex OR conditions from the original logic, I created separate rows for each domain rather than trying to combine them in one row.
2. Data Migration from Excel
The client provided an Excel file with all the conditions and expected outputs. Here's how I handled the conversion.
Started with manual entry to understand the pattern and Used ServiceNow's Decision Table import/export feature for the remaining rows
3. Inbound Action Code Update
Instead of hardcoded conditions in each inbound action, I replaced them with this standardized script:
//calling decision table and getting outputs.
var dt = new sn_dt.DecisionTableAPI();
var inputs = {};
inputs.u_from = email.from;
inputs.u_subject = emailSubject;
var response = dt.getDecision('38c4616ded29a61046c00df600b3542b', inputs);
var account_no = response.result_elements.u_account_number;
var assignment_group = response.result_elements.u_assignment_group;
var contact_email = response.result_elements.u_contact_email;
//complete inbound script is attached to this article.
4. Testing and Validation
Testing Process:
- Decision Table Testing: Used the built-in "Test Decision" functionality in the Decision Table UI
- Real Data Validation: Cross-checked outputs against the client's original Excel requirements
- Phased Deployment: Deployed one mailbox at a time to validate with actual incoming emails
- Client Verification: Had the client test with sample emails before full go-live
✅ The Results
Before: 60+ inbound actions After: 6 inbound actions (one per mailbox)
Key Benefits:
- Maintenance: Client can now update rules themselves with decision_admin role (no developer needed)
- Scalability: After go-live, client easily added missing rules through Decision Tables
- Growth: One Decision Table grew to 160 rows, another to 40 rows - still easier to manage than 60+ inbound actions
- Findability: No more searching through dozens of similar inbound actions
🛠️ Tips & Learnings
- Leverage "Duplicate Row" when adding similar logic in Decision Tables
- Always test with real emails or examples from client data
- Keep input and output field names consistent to reduce confusion
- Use Decision Table import feature for bulk updates instead of manual entry
- Handle OR conditions by creating separate rows rather than complex logic
🔚 Conclusion
Inbound email actions don't have to be messy. If you're dealing with multiple address combinations and rule sets — consider Decision Tables. They reduce noise in your configuration and empower clients to manage logic without touching a single line of code.
When to Use Decision Tables:
- You have repetitive logic that's just matching inputs to outputs
- Non-technical users need to maintain the rules
- You're dealing with multiple similar conditions with different outcomes
In the end, managing Decision Tables with 160+ rows was still far easier than maintaining 60+ nearly identical inbound actions. The client was happy, maintenance became simple, and the solution scaled beautifully.
✍️ About This Article
This article was written with inspiration and structural guidance from a LinkedIn post by @Earl Duque which you can find here:
https://www.linkedin.com/posts/earlduque_ai-servicenow-ugcPost-7341199379489243138-F2YS
Here’s the Complete inbound action script I used to call the Decision Table and populate the case fields in ServiceNow:
Thank you @Ravi Chandra_K @Laxman Chandra
Yes @Ravi Chandra_K Decision Table can be called from script and Flow designer too.
Adding link for reference - DecisionTableAPI - Scoped, Global
We do have 'code snippet' option available in decision table which gives us the exact code to be used.
