Overview
A Decision Table is a policy step that routes visit approvals based on combinations of policy field values using a single table. Instead of creating a web of condition steps and branches, you can define logic in one place, making complex policies easier to build, review, and maintain. Each row of a decision table is a rule, and each rule sends the visit to an output that becomes a branch on your canvas.
For the foundational step types (Policy fields, Conditions, and Approval steps), see Creating a Policy.
Decision Table vs. Condition steps
Both objects route a visit based on the values of policy fields. The difference is scale and readability:
Use a Condition step for simple, linear branching on a small set of fields with a limited number of outcomes.
Use a Decision Table when several fields and value combinations feed into a handful of outcomes, and you want to see and manage all of that logic in one table rather than across many branches on the canvas.
Anything you can model with multiple Condition steps can typically be represented in a Decision Table, but in a more condensed format. In general, it's best practice to keep your policy as clean and easy to read as possible.
A Decision Table produces the same kind of branches a series of conditions would, but it defines them in a compact, top-to-bottom table.
How a Decision Table works
A Decision Table has three parts:
Match by: the policy field(s) the table evaluates. You can select one or more fields to match on.
Rules: the rows of the table. Each rule sets the value(s) for the matched field(s) and assigns an output.
Outputs: the outcome each rule points to. Each unique output creates a separate branch on the canvas, where you build the subsequent steps (such as an Approval or Data Collection step).
Two behaviors are important to keep in mind:
Rules are evaluated top to bottom, and the first matching rule is applied. Order matters; place more specific rules above more general ones.
For example:
Rule 1: Nationality matches Dual National, Employee Type matches Contractor, output is Security Review
Rule 2: Nationality matches Dual National, Employee Type is Any, output is Manager Review
Because rules are evaluated top to bottom, a Dual National Contractor would be routed to Security Review rather than Manager Review.
Default handling catches any visit that doesn't match a rule and sends it down a default branch. The Default branch is required and is used whenever no rule matches. Make sure it represents a safe fallback path for
unexpectedorincompletedata.
PREREQUISITES
You will need to have built Policy fields to create your rules.
Adding a Decision Table step
In the Policy builder, click Decision Table to add the step to your workflow.
Click the new step to select it. Its details open in the right-hand side panel.
Give the step a clear Name. This label shows in the workflow builder, so keep it concise.
Click Set Up Rules to open the Decision Table editor.
Building Rules
In the Match by section, select the policy field(s) that the table should evaluate. The fields available here are the ones already defined in your policy's Policy Fields.
Each field you select becomes a column in the Rules table.
Each rule is a row that maps field values to an output.
Click + Add rule to add a row.
For each matched field, set the value the rule should look for (for example, What nationality is the visitor? = US or Dual National).
In the Output column, assign the outcome for this rule. Each unique output you enter becomes its own branch on the canvas.
Repeat adding rules for each combination you need to route.
Click Apply to save your table.
Because rules are applied top to bottom and the first match wins, order your rows from most specific to most general. Reorder rows so that narrower rules sit above broader ones.
š” Tip: Keep output names meaningful and reusable. Two rules that should reach the same outcome should share the exact same output, so they route to the same branch rather than creating duplicate branches. š”
Default handling
The Default handling row defines what happens to a visit that matches none of your rules. Every Decision Table includes this default so that no visit can pass through the table without a route. Make sure it represents a safe fallback path for unexpected or incomplete data.
Outputs and branches on the canvas
When you click Apply to finish building the table, each unique output (plus the default) appears as a branch, leaving the decision table step on the canvas. From there, build out the steps for each branch just as you would after a Condition, for example:
An Approval step for visits that need review.
A Data Collection step to gather admin-provided information.
A direct path to invite approval for low-risk visits.
A decision table with no rules is incomplete and will surface a validation error. Add at least one rule and build out each output branch before publishing your policy.