Rules Step
The Rules step evaluates business logic using a declarative rules engine. Instead of writing code, you define facts (your data) and rules (how to process it), and the engine automatically calculates outcomes. Perfect for pricing calculations, eligibility checks, conditional logic, and complex business rules.New to Rules? The Rules engine lets you build complex business logic without code. Think of it as a powerful decision-making engine for calculations, validations, and conditional outcomes.
How Rules Work
Rules evaluate facts (input data) against declarative rules to produce outcomes:When to Use Rules
| Use Rules When | Use Alternative When |
|---|---|
| Complex calculations (pricing, scoring) | Simple if/then (use Condition) |
| Multiple conditional outcomes | Single decision point |
| Business logic with many factors | Agent can interpret situation |
| Need transparent, auditable logic | Need learning/adaptation |
| Rules are clearly defined | Rules are fuzzy or contextual |
| Combining multiple conditions | Simple comparison |
❌ Use Condition instead: If age > 18, approve ✅ Use Rules: Multi-tier pricing with volume discounts, contract terms, add-ons
❌ Use Agent instead: Negotiate custom pricing based on customer relationship ✅ Use Rules: Loan eligibility with income, credit score, debt ratio, employment
❌ Use Condition instead: If credit score > 700, approve
Configuration
Facts (Input Data)
Input data for rules to evaluateCan reference previous steps:Each fact must have
.value suffix - this is required by the rules engineRules (Logic)
Rules to evaluate against factsTwo types of rules:
- Direct calculation - Simple formula
- Conditional rules - If/then logic
Rules syntax is powerful but can get complex. See detailed documentation for all operators and patterns.
Quick Start Example
Scenario: Calculate order discount based on tier and amount Input:Gold customer with 1,275
Detailed Rules Documentation
For complete rules syntax, operators, and advanced patterns, see the comprehensive Rules documentation:Rules Overview
Introduction to the rules engine and core concepts
Getting Started
Your first rule with step-by-step examples
Facts & Rules
Understanding facts and rule structure
Operators
All available operators (comparison, logical, arithmetic, string, array, date)
Conditions
Building complex conditional logic
Examples
Real-world rule patterns and use cases
Best Practices
Tips for writing maintainable rules
Common Flow Patterns
Pricing Calculation
Pricing Calculation
Calculate complex pricing with multiple factorsWhy Rules: Transparent pricing logic, easy to audit, no code needed
Eligibility Check
Eligibility Check
Determine if someone qualifies based on multiple criteriaWhy Rules: Clear requirements, consistent decisions, easy to update criteria
Lead Scoring
Lead Scoring
Score leads based on multiple attributesWhy Rules: Consistent scoring, easy to adjust weights, transparent criteria
Shipping Cost Calculation
Shipping Cost Calculation
Calculate shipping based on multiple factorsWhy Rules: Complex calculation, transparent to customers, easy to update rates
Discount Eligibility
Discount Eligibility
Determine which discounts applyWhy Rules: Multiple discount types, stacking rules, transparent logic
SLA Determination
SLA Determination
Calculate SLA based on customer tier and request typeWhy Rules: Consistent SLA application, easy to update policies
Risk Assessment
Risk Assessment
Assess risk level for transactions or applicationsWhy Rules: Clear risk criteria, auditable decisions, easy to adjust thresholds
Tiered Pricing
Tiered Pricing
Calculate pricing across multiple tiersWhy Rules: Complex tiered logic, transparent billing, easy to update tiers
Accessing Rule Outcomes
Reference rule outcomes in subsequent steps:Real-World Examples
Example 1: Insurance Premium Calculation
Scenario: Calculate car insurance premium based on multiple factorsExample 2: SaaS Pricing Calculator
Scenario: Calculate monthly SaaS pricing with features and usageExample 3: Loan Approval Decision
Scenario: Multi-criteria loan eligibility determinationBest Practices
Use Descriptive Names
Name facts and rules clearly:
customerTierDiscount.value not discount1.valueTest with Real Data
Test rules with actual values from your system. Edge cases matter.
Start Simple
Begin with basic rules, add complexity gradually. Test each addition.
Document Complex Logic
Add comments explaining why rules exist, especially business requirements.
Validate Inputs
Check that facts have expected types and ranges before evaluation.
Handle Edge Cases
Always include default outcomes for conditional rules (the final
{outcome: X}).Break Into Steps
For very complex logic, use multiple Rules steps. Easier to debug and maintain.
Version Your Rules
Track rule changes over time, especially for pricing and eligibility that affect customers.
Troubleshooting
Rule not evaluating
Rule not evaluating
Causes:
- Missing
.valuesuffix on facts or rules - Incorrect variable reference
- Wrong operator syntax
- Verify all facts end with
.value - Check variable paths:
"@fact:orderTotal.value"not"@fact:orderTotal" - Review operator syntax in documentation
- Check execution logs for error messages
Wrong outcome returned
Wrong outcome returned
Causes:
- Condition order wrong (first match wins)
- Logical operator error (AND vs OR)
- Data type mismatch
- Reorder conditions (most specific first)
- Verify logical operators
- Check data types (string “100” vs number 100)
- Add logging to see which condition matched
Can't access outcome in next step
Can't access outcome in next step
Causes:
- Wrong variable path
- Missing
.outcomesuffix - Rule didn’t execute
- Use
${rules_step_name.rule_name.value.outcome} - Check rule actually executed (logs)
- Verify step name is correct
Calculation incorrect
Calculation incorrect
Causes:
- Operator precedence issue
- Missing parentheses in complex math
- Wrong operator used
- Break complex calculations into steps
- Test each calculation piece separately
- Verify operator behavior in docs
- Use explicit nesting with operator objects
Performance slow with complex rules
Performance slow with complex rules
Causes:
- Too many conditions
- Nested loops in calculations
- Processing large arrays
- Simplify rule logic where possible
- Break into multiple Rules steps
- Filter data before rules
- Consider using agent for very complex logic
When to Use Rules vs. Alternatives
Use Rules when:- Logic is clearly defined and transparent
- Multiple factors combine to determine outcome
- Need auditable business logic
- Calculations involve multiple steps
- Requirements are likely to change (easy to update)
- Simple if/then (single decision point)
- Binary outcome (yes/no, approve/reject)
- No calculations needed
- Logic requires interpretation
- Need to understand context
- Rules are fuzzy or subjective
- Need to explain reasoning in natural language
- Need custom JavaScript beyond rule operators
- Highly dynamic logic that can’t be expressed in rules
- Integration with external libraries