Using Decision Tables and Workato Decision Models in Agentic Workflows
A Workato Decision Model maps input conditions to an output using a rule-based table evaluated top-to-bottom. Each row is one rule; the first matching row wins. Decision Models replace brittle nested IF/ELSE logic with a reviewable, auditable ruleset that business users can verify without reading code.
What Is a Decision Table?
A decision table is a structured mapping of conditions to outcomes. Each row represents one rule — a set of input conditions that, when all matched, produce a specific output. Rows are evaluated in order; the first row where all conditions are satisfied determines the result.
In the context of Workato's Decision Models: columns are variables, cells are conditions for that variable in that rule, all conditions in a row use AND logic, and rows themselves use OR logic relative to each other.
How Workato Decision Models Work
- Each row defines one rule with an associated output
- Evaluation is top-to-bottom; the first matching row wins
- Conditions within a row are ANDed — all must match
- Rows with OR logic are expressed as separate rows with the same output
- End with a catch-all row (no conditions) as a safe default or "flag for human review"
When to Use Decision Models in Agentic Workflows
| Use Decision Models When | Use Other Approaches When |
|---|---|
| Business rules have multiple contributing signals (e.g., usage + contract tier + region → license recommendation) | Logic is purely deterministic with a single condition (use a simple IF or formula) |
| Logic needs to be reviewable and maintainable by non-engineers | Rules are stable, simple, and unlikely to change (hardcode or use Properties) |
| Nested IF/ELSE logic is growing beyond 3–4 levels | Logic requires complex statistical or probabilistic reasoning (use LLM judgment) |
| Business logic changes frequently and needs a non-code review path | Conditions can't be expressed as discrete, enumerable values |
Decision Model Best Practices
- Use atomic input signals. Avoid pre-combined conditions as inputs — pass the raw signals and let the model combine them. "Usage tier: High" is better than "high-usage-enterprise-customer: true".
- Order most-specific rules first. More specific conditions should appear before broader ones. The catch-all row always goes last.
- Split OR conditions into separate rows. If two different condition sets produce the same output, write them as two rows with identical outputs.
- Always end with a catch-all. A row with no conditions that produces a safe default or "flag for review" output prevents unhandled cases from failing silently.
- Treat it as living documentation. Each row should read as: "If X and Y, then Z, because [business reason]." The table doubles as a spec non-engineers can audit.
Example: License Tier Recommendation
| Usage Score | User Count | Contract Type | → Output |
|---|---|---|---|
| High (>80%) | >100 | Enterprise | Recommend upgrade to Premium |
| High (>80%) | Any | Any | Flag for account review |
| Low (<20%) | Any | Any | Recommend downgrade evaluation |
| Any | Any | Any | No action required |
Decision Models vs. Properties vs. Hardcoded Logic
| Approach | Best For | Who Can Update |
|---|---|---|
| Decision Model | Multi-signal business rules that change frequently | Business users with table access |
| Data Table | Dynamic reference data (SKUs, thresholds, routing maps) | Business users, ops teams |
| Workato Properties | Environment-specific configuration (endpoints, flags) | Admins / engineers |
| Hardcoded | Truly static logic that never changes | Engineers only |