Decision Tables in ServiceNow: Smarter Email Routing by Location
In ServiceNow, we often face scenarios where decisions must be made based on multiple inputs—like location, department, or priority—and lead to specific actions. Writing custom scripts can work, but it often becomes messy, hard to maintain, and inaccessible to non-technical teams.
This is where Decision Tables come into play.
What Are Decision Tables?
A Decision Table is a structured, rule-based approach to evaluate conditions and determine outcomes. Instead of writing long if-else scripts, you define conditions as rows and actions as outputs. ServiceNow’s Decision Builder makes this process visual and much easier to manage.
Think of it as a lookup table: if certain conditions are met, ServiceNow executes the corresponding action.
Use Case: Email Routing by Location
Imagine you want to send incident notifications to different distribution lists depending on the user’s location.
- If the location is New York, send the email to NYC IT Support DL.
- If the location is London, send it to London IT Ops DL.
- If the location is Singapore, send it to APAC Support DL.
- For all other locations, send it to a Global Support DL.
This is a perfect use case for a Decision Table.
Implementing the Use Case
1. Enable Decision Builder
Make sure the Decision Builder plugin is active in your ServiceNow instance.
2. Create a Decision Table
Navigate to Decision Builder > Decision Tables and click New.
- Name: Location-Based Email Routing
- Table: Incident (or the table that contains location info)
- Execution Type: Synchronous
3. Define Conditions and Actions
Conditions (Inputs):
- Location
Actions (Outputs):
- Distribution List Email
| Location | Distribution List |
|---|---|
| New York | NYC IT Support DL |
| London | London IT Ops DL |
| Singapore | APAC Support DL |
| Default | Global Support DL |
4. Integrate with a Flow
Now, integrate this decision table with Flow Designer:
- Go to Flow Designer.
- Add a trigger, e.g., When Incident is created.
- Add a Decision Table action.
- Pass the Location field as input.
- Capture the output (Distribution List).
- Add a Send Email action → send the notification to the DL returned by the decision table.
Benefits of This Approach
- No scripting needed – admins can maintain rules in the table.
- Flexible – easily add new locations and DLs without code changes.
- Reusable – the same table can be used across multiple flows or business rules.
- Transparent – both technical and non-technical teams can read and update the logic.
Conclusion
By using Decision Tables in ServiceNow, you can replace complex scripts with a clean, maintainable, and reusable structure. In our example, email notifications are routed automatically to the right distribution lists based on location—keeping communication smooth and reducing manual effort.
If your organization manages multiple locations, consider adopting decision tables for email routing, approvals, or escalations. They’re a simple yet powerful way to bring clarity and automation into your workflows.
