Rule Engine

Rule engine

Overview

This node implements a Rule Engine that evaluates input data items against specified conditions or groups of conditions (rule groups). It filters the incoming data into two outputs: those that match the defined rules and those that do not. This is useful for scenarios where you want to route or process data differently based on complex logical conditions, such as filtering records, triggering workflows only when certain criteria are met, or validating inputs.

Practical examples:

  • Filtering customer records where age is greater than 18 and country equals "USA".
  • Routing orders with total amount above a threshold to a special processing workflow.
  • Validating form submissions by checking multiple fields against business rules.

Properties

Name Meaning
Rule Group A collection of conditions grouped together. Each group can contain multiple conditions combined logically.
Conditions Individual conditions to evaluate against each input item.
Convert types where required (looseTypeValidation) If enabled, the node attempts to cast values to compatible types during comparison (e.g., string "false" to boolean false). Default is false in newer versions, true in older versions.
Options > Ignore Case Whether to ignore letter case when evaluating string comparisons in conditions. Defaults to true.
Options > Convert types where required Same as looseTypeValidation but shown in options for older versions of n8n.

Output

The node outputs two arrays of items:

  • The first output contains all input items that matched the specified conditions or rule groups (i.e., evaluated to true).
  • The second output contains all input items that did not match the conditions (i.e., evaluated to false).

Each output item retains its original structure and data. There is no binary data output from this node.

Dependencies

  • No external services or API keys are required.
  • Uses lodash library internally for utility functions.
  • Requires n8n environment version 2.1 or higher for some features like strict type validation.

Troubleshooting

  • Common issues:

    • Misconfigured conditions may cause unexpected filtering results.
    • Type mismatches between input data and condition values can lead to evaluation errors unless "Convert types where required" is enabled.
    • Case sensitivity settings might affect string comparisons unexpectedly.

  • Error messages:

    • Errors related to type validation will suggest enabling the "Convert types where required" option to allow automatic casting.
    • NodeOperationError or ApplicationError instances include context about which item caused the failure, aiding debugging.
    • If the node is set to continue on fail, it will pass failed items to the second output instead of stopping execution.

Links and References

Discussion