Decision Table

A Decision Table is the most popular rule type in DecisionRules — and the first one most teams reach for. It turns business logic into a structured grid where each row is a scenario: a specific combination of conditions that leads to a defined output. Pricing tiers, eligibility rules, fee structures, approval logic, tax rates, routing rules — if your logic can be written in a spreadsheet, it belongs in a Decision Table. No code, no developer required to build it or maintain it.

Decision Tables have three column types. Input columns hold the conditions evaluated against incoming data. Output columns hold the values returned when a row matches. Calculation columns are intermediate columns that compute a derived value per row — think of them as named variables scoped to that row's evaluation. They keep your table clean by avoiding repeated formulas across multiple output columns, and their value can differ per row while staying consistent within it.

See our documentation on Table Designer for details.

Operators define how each condition in a row is evaluated against the incoming data. You pick the field from your input model, choose an operator, and set the value to compare against — every condition in a row must pass for it to match and return its output. Operators cover everything you'd expect: equals, not equals, greater than, is null and more.

Two special operators are worth knowing: ANY makes a condition always pass regardless of the input value; ELSE triggers only when no other row in the table has matched — the cleanest way to define a default or fallback response.

See the full list of Basic operators and Date operators in our documentation.

Use a Decision Table when your logic is parallel — when you're evaluating many combinations of inputs against a flat set of rules and returning a result. Decision Tables are best for flat, coverage—based logic: here are all the scenarios, here are their outcomes.

Use a Decision Tree when your logic branches — when the path through the decision depends on the outcome of earlier conditions. Decision Trees shine for sequential, multi—level reasoning where one answer unlocks the next question.

A Decision Table contains your business logic — it evaluates conditions and returns decisions. A Lookup Table contains your business data — it stores values your rules need to reference.

For example: a Decision Table might say if country = US, apply fee structure, while a Lookup Table stores the actual fee values for each country. They work together: your Decision Table reads data from your Lookup Table to make smarter decisions.

Any logic that a business analyst would naturally write in a spreadsheet. Pricing rules, discount tiers, credit scoring bands, product eligibility, shipping cost calculations, tax rate lookups, fraud risk thresholds, SLA routing — if the logic involves mapping combinations of inputs to defined outputs, a Decision Table handles it cleanly. It's also the best starting point for business users who need to own and maintain rules without developer involvement.

Yes — the Decision Table editor is designed to feel exactly like the spreadsheet tools your team already uses. Click a cell to select it, use arrow keys to navigate, Tab to move across columns, Enter to confirm and move down. Select a range with Shift+Click, select entire rows by clicking row headers.

If you've used Excel or Google Sheets, you already know how to use it.

Yes. Any row can be deactivated — it stays in the table, stays visible, but is skipped entirely during evaluation. This is useful for staging new logic before it goes live, disabling seasonal rules without losing them, or keeping historical rows for reference. Reactivate with one click when you're ready.

You control this with the execution strategy. The default Standard strategy returns all matching rows in the order they appear in the table. First Match returns only the first matching row — useful when you want a single, prioritised result. Array returns all matches grouped into arrays. Evaluate All runs every row regardless of match and returns each one with a flag indicating whether it matched or not, giving you full visibility over the entire table's evaluation.

See our documentation on Execution Strategy for details.

Enable Debug Mode in the Test Bench and run your input — the table comes alive. Every condition cell turns green if it passed or red if it failed, and each cell shows the actual value the engine compared against your input. Matching rows are highlighted so you see at a glance exactly why a row fired or didn't. It's the fastest way to understand unexpected results without leaving the editor — you see the full evaluation, not just the final output.

See our documentation on Debug Mode for details.

Yes — every row supports time validation. Set a from and to date and time range on any row, and the engine will only evaluate that row within that window. Outside of it, the row is skipped entirely, as if it were inactive. It's the cleanest way to handle seasonal pricing, promotional rules, temporary overrides, or any logic that should only apply for a defined period — no manual activation needed, no risk of forgetting to turn it off.

See our documentation on Time Validation for details.

Valid Values let you restrict what can be entered in a cell to a predefined set of allowed values. There are three ways to define them: a simple array of values, a regex pattern, or a reference to a Lookup Table. Valid Values are most useful when a column has a fixed set of meaningful options — country codes, product categories, status values — and you want to prevent free-text mistakes.

See our documentation on Valid Values for details.

Just like in Excel or Google Sheets, the formula bar sits above the table and always shows the value and operator of the selected cell. You can edit directly in it — changes sync back to the cell in real time. It's especially useful for longer expressions or complex functions that are hard to read inside a small cell. The formula bar is resizable so you can expand it as needed.

Autofill works like it does in Excel. Select a cell or range, then drag the blue square that appears at the bottom-right corner in any direction — down, up, left, or right. If the source values form an arithmetic sequence (1, 2, 3 or 10, 20, 30), Autofill continues the pattern automatically. For non-numeric or irregular values, it cycles through the source values and repeats them across the target range.

Functions let you express computed logic inside cells — mathematical operations, string manipulation, date calculations, conditional expressions, and more. DecisionRules has a full library of built-in functions that can be nested and combined.

Writing functions is also where the AI Assistant comes in: select any cell in the Decision Table and ask the AI Assistant to generate a function expression for it. The assistant is aware of the cell's context — available input variables, the current operator, the table structure — so it generates correct expressions rather than generic code.

See the full Functions reference in our documentation.

Yes. Open the AI Assistant from the Rules List and describe the logic you need in language — a pricing table for three subscription tiers with monthly and annual billing or an eligibility rule based on age, income, and employment status. The assistant builds the input/output model, creates the columns, and populates rows based on your description. It can ask follow-up questions when your description is ambiguous.

The result is a working table you can run immediately or continue refining through the assistant.

Yes. Ask it to summarise the rule and it reads your entire table and generates a plain-language description of the logic — what conditions it covers, what outputs it returns, and how the rows relate to each other. Useful for documentation, onboarding new teammates, or preparing a rule for a business review without requiring anyone to read the table itself.

Learn more in our documentation .

Yes. Just ask — it knows your table's structure and can generate real-world inputs, inputs designed to match specific rows, inputs targeting edge cases or boundary conditions, or inputs that intentionally don't match any row to expose gaps in your coverage. You can also describe what you want: give me an input that matches row 3 or generate a case that hits the ELSE row.

Learn more in our documentation .

Yes. Click on a cell and ask the assistant to write a function for it — the assistant sees the cell's context, including available input variables and the current operator, and generates a correct, ready-to-use expression. It can also explain what an existing function does, debug one that isn't returning the expected result, and combine multiple functions for more complex logic.

Learn more in our documentation .

Yes. Just describe what you're looking for — where do I set the execution strategy or how do I add a new column — and the assistant highlights the exact element in the interface. Useful when you're new to the platform or working in a part of the editor you don't visit often.

Learn more in our documentation .

Excel (.xlsx) and JSON. Excel export is perfect for teams who prefer to work in spreadsheets — even though the Decision Table editor already feels like one, some people simply prefer to do bulk edits in a tool they've used for years. Export your table, make changes in Excel, and import it straight back. JSON is the right choice when you need to migrate rules between spaces, restore from backup, or automate deployments via the Management API.

See our Management API documentation for details.

Yes — two ways. If you have access to both spaces, you can share the rule directly between them using Share with Space. If you don't have access to the target space, export the rule as JSON and send the file — importing it recreates the full rule exactly as it was. The whole process can also be automated via the Management API for teams running deployment pipelines.

See our Management API documentation for details.

Yes. Copy a range and paste it directly into the table with Ctrl+V. If the pasted data goes beyond the current table bounds, new rows are created automatically.

Any rule type can call a Decision Table using the SOLVER function — Scripting Rules, other Decision Tables, and Flows... The most common pattern is using a Decision Table as a node inside a Flow, where it handles one layer of logic as part of a larger automated process. You can also call a Decision Table directly via the Rule Solver API as a standalone rule.

Yes. Any rule or Flow in your workspace can call the same Decision Table via its rule ID or alias. Using an alias is the recommended approach — you can configure the calling rule to always use the latest published version, so the moment you publish an updated table, every caller picks it up automatically. One publish, everything stays current.

Yes — and there are two types of history. Rule history is auto-saved every time you click Save, capturing your changes in the rule's edit history. You can browse and restore any of these auto-saves at any time. Versions are manual snapshots you create explicitly when making bigger changes. You can name these versions, compare them, and roll back to any previous version with one click.

Both types of history give you full safety and control over your data.

See our documentation on Versioning and Rule History for details.

Permissions are fully customizable at multiple levels — space, account, team and roles. You can grant edit access to specific users, restrict others to read-only, or set up approval workflows for production changes.

See our documentation for how to configure granular access control.

Yes. The Management API supports full Decision Table management — create, update, publish new versions, and sync from external systems without touching the UI. Ideal for automated deployment pipelines, nightly data refreshes, or keeping rules in sync with an external source of truth.

See our Management API documentation for details.

Let the logic guide you, not the size. Each Decision Table should represent one decision — pricing, eligibility, routing — with a clear input and a clear output. If two unrelated decisions are sharing the same table, split them. Smaller, focused tables are easier to test, easier to hand off to a business owner, and easier to reuse across different Flows.

That said, there are also hard limits to keep in mind: a single table supports up to 40,000 rows, 40 columns, and 80,000 cells. If you're approaching those boundaries, splitting is the right move regardless.

See our Structure Limits documentation for details.

When the same values appear across multiple rules, or when the data changes more often than the logic does. If you're hardcoding fee amounts, country codes, or product configurations directly into table cells, any change means editing the table itself — and potentially breaking the logic. Move that data into a Lookup Table, reference it from your Decision Table, and updates become a data change rather than a rule change. Business users can update the values independently without ever touching the logic.

See how to use Lookup Table with Decision Table in our documentation .

Whenever a value is used in more than one place, or whenever a non-developer might need to change it. Rule Variables let you define a value once — a promo code, a threshold, a multiplier — and reference it across the entire table. When the value needs to change, you update it in one place in Rule Settings and every row that uses it updates automatically.

No hunting through cells, no risk of missing one.

Save constantly — every save is captured in Rule History and can be restored at any time. Create a named version when you're about to make a significant structural change, before a major data import, or before publishing to production. Think of saving as autosave and versions as a manual snapshot before something important.

Versions also give you precise control over which rules call which data. One process can always call the latest published version, while another stays locked to version 3 and a third to version 5 — all from the same table. This makes it safe to iterate and test new logic without affecting any caller that isn't ready for the change yet.