usertasks
All documentationStart free beta
Documentation hub

Feature guide

Decision tables

Centralize typed, ordered business rules and return consistent outputs to workflows and applications.

On this page

Complete feature description

Understanding decision tables in UserTasks

Decision Tables centralize business policy as typed inputs, ordered conditions, and structured outputs. They are designed for logic that changes more often than the surrounding workflow, needs review by process owners, or must behave consistently across several automations.

Each table declares an input contract and an output contract. Rules compare the supplied facts and the first enabled matching rule returns its output values. The explicit no-match result lets the caller handle incomplete policy coverage instead of silently choosing a default.

Workflows map variables into the decision table and receive matched state plus named outputs. Designers can test representative facts directly in the table before connecting it to production processes.

When to use this feature

  • Policy logic contains many value bands or combinations.
  • Rules must be reviewed independently from workflow structure.
  • Several workflows need the same eligibility, routing, pricing, or approval decision.
  • Business users need safe changes without editing a large canvas.

What you can build

  • Approval-level calculation
  • Eligibility and entitlement decisions
  • Risk classification
  • Routing and assignment policy
  • SLA selection
  • Discount, fee, or service-tier determination

Production design notes

  • Put specific exception rules above broad rules because first match wins.
  • Always test boundary values, null values, and a no-match scenario.
  • Use typed outputs with stable keys and avoid embedding downstream action details in the table.
  • Include a deliberate fallback rule when the policy should always produce a result.

Core concepts

Typed contract

Inputs define the facts a decision requires; outputs define exactly what a caller receives.

Ordered rules

Enabled rules are evaluated in order and the first matching rule returns its output values.

Central maintenance

Process owners can update policy logic without rebuilding every workflow branch.

Testability

Sample facts can be evaluated before connecting the table to runtime workflows.

Before you start

Have these permissions, assets, and design decisions ready.

  • Permission to manage decision tables
  • A defined set of input facts
  • Explicit outputs the workflow or application expects
  • Rule order and fallback behavior agreed with process owners

Detailed input and result reference

These are the values designers configure and the results available after execution. Exact fields can vary by operation, but the runtime contract follows these patterns.

Define inputs

Declare the facts each rule can evaluate.

Inputs

keystringrequired

Stable programmatic input name.

Example: amount
labelstringrequired

Designer-facing name.

Example: Request amount
typestring | number | boolean | daterequired

Controls comparisons and validation.

Expected results

input schemaarray

Typed contract shown to workflows and test tooling.

Define outputs

Declare the values returned by a matching rule.

Inputs

keystringrequired

Stable output name.

Example: approval_level
labelstringrequired

Readable output label.

typestring | number | boolean | daterequired

Expected result type.

Expected results

output schemaarray

Typed keys available to downstream workflow nodes.

Create ordered rule

Match input conditions and return one output object.

Inputs

conditionsobjectrequired

Per-input operators and comparison values.

outputsobjectrequired

Values returned if the rule matches.

priority / ordernumberrequired

Rules are evaluated in displayed order.

enabledboolean

Disabled rules are skipped without deletion.

Expected results

matchedboolean

True when the rule is selected.

matched_ruleidentifier

Rule used to explain the decision.

outputsobject

Typed result values.

Runtime behavior

  • The first matching enabled rule wins.
  • Unsupported or invalid comparisons do not silently coerce incompatible types.
  • A no-match result is explicit and can be handled by the caller.

Test decision

Evaluate sample facts before connecting the table to a workflow.

Inputs

input valuesobjectrequired

One value for each required input.

Expected results

matchedboolean

Whether any rule matched.

outputsobject

Returned values for the sample.

tracerule information

Which rule produced the result.

Evaluate from workflow

Map workflow context into the table and expose outputs.

Inputs

decision_table_idUUIDrequired

Selected table.

input_mappingsobjectrequired

Workflow expressions for every table input.

Expected results

matchedboolean

Available for a following branch.

outputsobject

Complete result object.

individual keysworkflow variables

Each output key can be used downstream.

Step-by-step implementation guides

Route purchase requests by value and risk

Expected outcome: The workflow receives a consistent approval level and SLA from centrally managed rules.

  1. 1

    Define inputs

    Add amount:number, risk:string, and preferred_vendor:boolean.

    Result: The decision contract is explicit and typed.

  2. 2

    Define outputs

    Add approval_level:string, sla_hours:number, and auto_approve:boolean.

    Result: Every matching rule returns values the workflow understands.

  3. 3

    Add ordered rules

    Put the most specific high-risk conditions first, followed by value bands and a fallback rule.

    Result: First-match behavior is predictable and reviewable.

  4. 4

    Test examples

    Run low-value preferred, high-value, and high-risk samples.

    Result: Process owners can verify results before activation.

  5. 5

    Use in workflow

    Map form values into Decision Table and branch on auto_approve or approval_level.

    Result: Rule changes take effect without rebuilding the workflow graph.

Actions and capabilities

What designers and operators can do in this product area.

Decision tables actions

The main operations available in Decision tables.

Decision tables actions

Define inputs and outputs

Create stable typed keys for facts and decision results.

Example: Return an approval level and SLA from request amount, department, and risk.
Configuration inputs
  • Permission to view and edit the relevant decision tables assets.
  • The target decision contract, ordered rules, test inputs, and typed outputs.
  • Any required mappings, recipients, filters, variables, permissions, or lifecycle settings shown by the designer.
How to use it
  1. 1.Open Decision tables from the main navigation.
  2. 2.Create or open the relevant asset and choose “Define inputs and outputs”.
  3. 3.Complete the required fields, map dynamic values, and review access to every referenced asset.
  4. 4.Use preview, test, or validation where available; correct errors before publishing or executing.
  5. 5.Run the action and inspect its status, output, history, or audit record.
Expected results
  • Callers receive a consistent first-match decision and structured output values.
  • Failures remain visible with enough context to correct configuration or retry safely.

Decision tables actions

Create and order rules

Configure conditions, output values, enabled state, and first-match order.

Example: Return an approval level and SLA from request amount, department, and risk.
Configuration inputs
  • Permission to view and edit the relevant decision tables assets.
  • The target decision contract, ordered rules, test inputs, and typed outputs.
  • Any required mappings, recipients, filters, variables, permissions, or lifecycle settings shown by the designer.
How to use it
  1. 1.Open Decision tables from the main navigation.
  2. 2.Create or open the relevant asset and choose “Create and order rules”.
  3. 3.Complete the required fields, map dynamic values, and review access to every referenced asset.
  4. 4.Use preview, test, or validation where available; correct errors before publishing or executing.
  5. 5.Run the action and inspect its status, output, history, or audit record.
Expected results
  • Callers receive a consistent first-match decision and structured output values.
  • Failures remain visible with enough context to correct configuration or retry safely.

Decision tables actions

Test sample decisions

Evaluate representative inputs and inspect the selected rule and outputs.

Example: Return an approval level and SLA from request amount, department, and risk.
Configuration inputs
  • Permission to view and edit the relevant decision tables assets.
  • The target decision contract, ordered rules, test inputs, and typed outputs.
  • Any required mappings, recipients, filters, variables, permissions, or lifecycle settings shown by the designer.
How to use it
  1. 1.Open Decision tables from the main navigation.
  2. 2.Create or open the relevant asset and choose “Test sample decisions”.
  3. 3.Complete the required fields, map dynamic values, and review access to every referenced asset.
  4. 4.Use preview, test, or validation where available; correct errors before publishing or executing.
  5. 5.Run the action and inspect its status, output, history, or audit record.
Expected results
  • Callers receive a consistent first-match decision and structured output values.
  • Failures remain visible with enough context to correct configuration or retry safely.

Decision tables actions

Evaluate from workflow

Map workflow values into the table and expose matched state plus output keys.

Example: Return an approval level and SLA from request amount, department, and risk.
Configuration inputs
  • Permission to view and edit the relevant decision tables assets.
  • The target decision contract, ordered rules, test inputs, and typed outputs.
  • Any required mappings, recipients, filters, variables, permissions, or lifecycle settings shown by the designer.
How to use it
  1. 1.Open Decision tables from the main navigation.
  2. 2.Create or open the relevant asset and choose “Evaluate from workflow”.
  3. 3.Complete the required fields, map dynamic values, and review access to every referenced asset.
  4. 4.Use preview, test, or validation where available; correct errors before publishing or executing.
  5. 5.Run the action and inspect its status, output, history, or audit record.
Expected results
  • Callers receive a consistent first-match decision and structured output values.
  • Failures remain visible with enough context to correct configuration or retry safely.

Potential use cases

Patterns you can adapt to your own operating model.

Approval routing

Calculate approval level and SLA from amount, department, and risk.

Map request facts
Evaluate ordered rules
Return approval level
Create correct user task

Eligibility decision

Apply consistent eligibility rules across forms, workflows, and API-driven processes.

Validate typed inputs
Evaluate policy
Return eligibility and reason
Branch or notify