Decision Table
A Decision Table is a Salesforce Industries / OmniStudio Business Rules Engine artifact that maps input columns to output columns in a spreadsheet-like grid.
Definition
A Decision Table is a Salesforce Industries / OmniStudio Business Rules Engine artifact that maps input columns to output columns in a spreadsheet-like grid. Each row is a rule: given a set of input values (or ranges), the matching row's output columns are returned. Decision Tables are how policy, pricing, eligibility, and tier logic gets configured without writing Apex, and they are versioned and deployable as metadata.
The table is part of the Business Rules Engine (BRE) that sits inside OmniStudio (formerly Vlocity) and underpins many Salesforce Industries clouds. You define it through the Decision Table Designer or by importing a CSV. Expression Sets and Calculation Procedures invoke a Decision Table by name, pass in the input columns, and receive the matched output. The first matching row wins by default, though you can configure all-matches behavior for cumulative rules.
How Decision Tables work in OmniStudio's Business Rules Engine
Inputs, outputs, and rule rows
A Decision Table has input columns (the conditions) and output columns (the results). Each row pairs input values or ranges with an output set. Input cells can be exact values, comparison operators (<, <=, =, >=, >), or ranges (10..20). Output cells are constants, formulas, or references to other tables. The engine reads the table top to bottom, matches the first row whose inputs satisfy the supplied values, and returns that row's outputs.
First-match versus all-match modes
By default, a Decision Table runs in first-match mode: the engine stops on the first satisfying row. This is the right semantics for cascade rules where order matters (eligibility tiers, lookup hierarchies). All-match mode returns every satisfying row, useful for cumulative logic like adding fees from multiple applicable tiers. The mode is set at design time and changes the engine's optimization strategy under the hood.
CSV import and the round-trip workflow
Most production Decision Tables originate as CSVs. The Designer accepts an import that maps CSV columns to input and output column definitions, and a corresponding export produces a CSV you can edit in Excel. The round-trip pattern is the typical workflow: domain experts manage the rules in a familiar spreadsheet, then upload back into Salesforce when changes are ready. The table activates on save.
Versioning and the Active flag
Each Decision Table has versions. A new version starts In Development and shows in the Designer for editing. Setting Active flips the published flag and routes incoming requests to that version. Older active versions are deactivated automatically; older In Development versions stay editable as drafts. This is how Salesforce gets you safe deployment without a separate dev/test/prod boundary inside the table itself.
Calling a Decision Table from an Expression Set
Decision Tables rarely run standalone. They sit inside an Expression Set (the BRE's higher-level orchestration), invoked as a Lookup step that maps a request's fields to the table's input columns. The output flows into subsequent steps: another Decision Table, a Calculation Matrix, or a formula. This composition is what lets you build sophisticated underwriting, pricing, or eligibility logic out of small, reviewable tables.
Performance and the lookup index
The BRE builds an internal lookup index over the input columns when a table is activated. Exact-match inputs are indexed for O(log n) lookups; range-based inputs do interval matching with similar performance. A table with 100,000 rows and well-typed inputs returns lookups in milliseconds. A table with 10 rows but free-text comparisons is paradoxically slower because the engine cannot index it. Design input columns as typed (numeric, picklist, exact-string) wherever possible.
Decision Tables versus Flow Decisions versus formula fields
Flow's Decision element branches a Flow based on a condition, but it does not scale to 50 rules. A Salesforce formula field can encode three or four cases through CASE() but becomes unreadable past that. Decision Tables shine when you have 20 or more rules driven by tabular inputs that domain experts want to read and edit. The same logic in Flow or Apex is reviewable only by developers; in a Decision Table, a product manager can audit it.
How to create a Decision Table in OmniStudio
Decision Tables are built in the OmniStudio Business Rules Engine Designer. The fastest path is to start with a CSV of your rules and import; the Designer then lets you refine inputs, outputs, and version the table for deployment.
- Open the BRE Designer
OmniStudio app, then Business Rules Engine tab, then Decision Tables, then New. Give the table a name (PriceTier_ByQuantity, EligibilityCheck_ByState) and a brief description.
- Define input and output columns
On the Columns tab, add input columns one per condition (Quantity, State, CustomerType) and output columns one per result (PricePerUnit, DiscountPct, Notes). Choose the right data type for each: numbers, picklists, and dates have distinct comparison semantics.
- Add rule rows
On the Rules tab, add a row per rule. Fill in the input cells with values, ranges (10..50), or comparison operators (>= 100). Fill in the output cells with constants or formulas. Order matters in first-match mode: put the most specific rules at the top.
- Import from CSV if you have one
From the Designer, use Import to upload a CSV. Map the CSV columns to input and output column definitions. The Designer warns about type mismatches and unmapped columns before committing.
- Save and activate the version
Save the draft. When the rules look right, click Activate. The previous active version is automatically deactivated, and incoming requests start hitting the new rules.
- Invoke from an Expression Set
In an Expression Set, add a Decision Table Lookup step. Pick your table, map the request's fields to the input columns, and route the output columns to subsequent steps or to the response.
The engine returns the first row whose inputs match. Order-sensitive rules belong here. Default for most policy and eligibility tables.
The engine returns every matching row. Used for cumulative logic like layered fees or stacked discounts.
Numeric, picklist, text, date. Typed inputs are indexed for fast lookup; free-text inputs are not.
Constants, formulas, or references to other tables. Formula outputs let you compute derived values without a separate calculation step.
- First-match order matters. A general rule above a specific one shadows the specific one. Always test edge cases after reordering.
- Activation deactivates the prior version. There is no automatic A/B test; if you need staged rollout, route different request types to different table names.
- CSV imports overwrite existing rows. The Designer warns you, but a careless import can wipe your tuned table. Export first, then import the edited version.
- Decision Tables are part of OmniStudio. Orgs without OmniStudio licensing do not have access; check the licensing constraint before designing around them.
Trust & references
Straight from the source - Salesforce's reference material on Decision Table.
- Decision Tables OverviewSalesforce Help
- Create a Decision TableSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Decision Table?
Q2. Who is the Decision Table format designed for?
Q3. What are common Decision Table use cases?
Discussion
Loading discussion…