Stop Hardcoding Business Logic - Use Decision Tables instead

[SujanDutta]

If you've been building on ServiceNow for any length of time, you've probably inherited (or built) one of those flows. You know the ones — a sprawling mess of if-else branches, dozens of update record actions, and logic that's copy-pasted across multiple workflows. It works... until someone in the business changes a rule and suddenly you're spelunking through five different flows to update the same condition.

Decision Tables fix this. And honestly, they don't get nearly enough attention for how much cleanup they can do.

What Are Decision Tables?

Think of them as structured, reusable logic charts. You define your input conditions (columns on the left) and your output results (columns on the right), fill in the rows with your business rules, and then reference that table from anywhere on the platform — Flow Designer, Playbooks, platform scripts, or wire API calls.

The key insight is separation of concerns: your workflows execute logic, they don't store it. The decision table becomes the single source of truth. Change the table, publish it, and every workflow that references it picks up the new logic immediately.

The Three Problems Decision Tables Solve

1) Developer dependency: Business logic changes shouldn't require a developer sprint. With decision tables, business users can export the logic to Excel, make their edits, import it back, and publish — all within minutes.

2) Scattered logic: When the same routing or approval logic lives inside multiple flows, keeping them in sync is a nightmare. A decision table centralizes it in one place.

3) Collaboration gap: The people who understand the business rules (legal teams, operations managers, compliance folks) aren't always the people who can edit a flow. Decision tables bridge that gap.

 

Use Case 1: Incident Routing

The scenario: incoming incidents need to be routed to different assignment groups with the correct escalation level and SLA, based on priority, category, and VIP status.

The legacy approach? A tangled flow with multiple if-else branches and separate update record actions for every combination. Each branch hardcodes the assignment group, escalation, and resolution time.

With a decision table, the flow becomes three steps: trigger → make a decision (which returns assignment group, escalation, and SLA) → update the record. That's it. All the routing logic lives in the decision table, not the flow.

 

Use Case 2: Catalog Request Fulfillment

For catalog items, you need to determine the fulfillment group and whether approval is required based on category, subcategory, and price thresholds.

The old-school flow had 19 steps. The decision table version? Four steps. The flow triggers on a catalog request, calls the decision table to get the fulfillment group and approval flag, checks if approval is needed, and updates the request. Clean, readable, maintainable.

 

Use Case 3: Change Approval Policies

Change requests have their own complexity — change type, risk level, category, and subcategory all factor into which approval group handles it, what approval level is required (manager, director, auto-approve), and the SLA target.

A 24-step legacy flow collapses to roughly 4 steps with a decision table handling the logic. The flow just asks the decision table for the outputs and acts on them.

 

The Excel Export/Import Trick

This is the feature that makes decision tables genuinely accessible to non-technical users. You can export the entire decision table to Excel, hand it to a business stakeholder, let them add or modify rows, and import it back. No platform expertise required. No developer tickets. No waiting.

One real-world example from the episode: a legal team was managing complex approval logic that varied by region and time period. Before decision tables, every change required developer involvement. After? The legal counselors maintained the logic themselves, with full data confidentiality, and could push changes to production immediately.

 

More Use Cases Worth Exploring

The three deep-dives above are just the starting point. Teams are actively using decision tables for eligibility and compliance rules (determining benefits, licensing, and certifications based on employee attributes), security incident routing (sending incidents to specialized teams based on severity and asset type), approval thresholds (routing approval requests based on dollar amount, department, and request type), discount and pricing logic (governing customer discounts dynamically), and integration routing (deciding which API endpoint to call based on conditions, then invoking the right subflow dynamically).

 

The Bottom Line

Decision tables are included in every ServiceNow subscription. They're not a premium add-on, not a separate license — they're just sitting there, ready to untangle your flows. If you've got business logic hardcoded in workflows today, this is one of the highest-ROI cleanup projects you can take on.

Go try it. Your future self (and the business users waiting on your flow changes) will thank you.