> For the complete documentation index, see [llms.txt](https://docs.brigge.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brigge.ai/documentation/brigge-for-transformers/pipelines/pipeline-nodes/route-node.md). # Route node ## Overview The *Route* node sends incoming payloads down multiple branches for processing, based on a given set of rules. After adding a `route` node, you define required branches and the associated rules that determine whether a payload flows through them. Once this is done, the *Route* node is added to the pipeline with a 'stub' for each branch. You can then add nodes to each branch to define how routed data is processed. A simple use case for the route node is when data received from a source connector includes a mix of data from three countries, but the data for each country must be processed slightly differently. In this case, a *Route* node is defined with three branches, each configured to filter incoming data on a `country` field:

{% hint style="info" %} It's not mandatory to add *multiple* branches for a *Route* node. For example, you might add a *Route* node with a single branch after a [connector](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/connector-node.md) node to filter incoming data. {% endhint %} ## Configuring a route node {% stepper %} {% step %} **Add a route node** Add a *Route* node to your pipeline and access settings:

{% endstep %} {% step %} **Select a schema** Select the schema associated with the payload structure you expect the *Route* node to receive. {% hint style="info" %} You don't have to provide a schema, but it's useful for navigating the expected payload structure when configuring branch rules based on incoming field values. {% endhint %} {% endstep %} {% step %} **Add branches** By default, route nodes are added with one branch. Use the 'plus' option to add more. {% endstep %} {% step %} **Configure branches** Click a branch name to access configuration options:

Configuration options are summarised below:

Branch setting Summary

Name Enter a name for this branch. This name is displayed on the canvas.

Array behaviour

Branch setting	Summary
Name	Enter a name for this branch. This name is displayed on the canvas.
Array behaviour	If your branch rules include fields that return an array value, use these options to determine how those arrays are evaluated for a match. For example, suppose a rule is defined to match on a `staff_id` field, which is an array. For example: `"staff_id": [{"id":"FIN-2001"},{"id":"ENG-1001"}]` You need to decide if the rule results in a match if ALL array items match criteria or if ANY array item matches rule criteria. Note: The `array behaviour` options are only applicable for rules based on array fields. They are ignored for other field types. If you define multiple rules based on different array fields, your `array behaviour` setting applies to all of them.
Rules	Use the rule builder to define rules that must be met for data to flow down this branch. For guidance on defining rules, see Using the rule builder.

If your branch rules include fields that return an array value, use these options to determine how those arrays are evaluated for a match.

For example, suppose a rule is defined to match on a staff_id field, which is an array. For example:

"staff_id": [{"id":"FIN-2001"},{"id":"ENG-1001"}]

You need to decide if the rule results in a match if ALL array items match criteria or if ANY array item matches rule criteria.

Note:

The array behaviour options are only applicable for rules based on array fields. They are ignored for other field types.
If you define multiple rules based on different array fields, your array behaviour setting applies to all of them.

Rules Use the rule builder to define rules that must be met for data to flow down this branch. For guidance on defining rules, see Using the rule builder.

Using the rule builder

A *rule* is a three-part query:

Part	Summary	Example
Field/key	The incoming data field to be considered for matching.	`staff_id`
Operator	The relationship between the given field and value. Choose from equals, not equals, greater than, less than, greater than or equal to, less than or equal to.	`!=`
Value	The value to be matched.	`Finance`

Rules are organised in groups. If your requirements are simple (for example, select all records where the `id` field `=` `1001` AND `hours_worked` `>` `0`) then you simply [add rules](#user-content-fn-1)[^1] to the default group and [choose the `AND/OR` relationship](#user-content-fn-2)[^2] between them. For more complex requirements, you can [add more groups](#user-content-fn-3)[^3]. In this case, you [choose the `AND/OR` relationship between the groups](#user-content-fn-4)[^4] and also [for the rules within them](#user-content-fn-2)[^2]. Taking our example, we have one group of `staff_id` numbers that must be excluded from selection, and two `department` values to target. So, we are saying: *Select all data where the department field is set to either Finance or Engineering AND the staff\_id value is not PROD-500, PROD-501, or PROD-502.* {% hint style="info" %} Within groups, rules are processed sequentially. Use associated icons to move a rule to a new position, or to remove a rule from the group: ![](https://2172380191-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8IqdqwZowcxtFpZfLa6k%2Fuploads%2FrKYToYnVPpUDgfn7pYNT%2FData%20warehouse%20node%20-%20rule%20builder%202a.svg?alt=media\&token=a920c5a6-4521-4a97-8572-0808eac7507f) {% endhint %}

{% endstep %} {% endstepper %} [^1]: (1 above) [^2]: (2 above) [^3]: (3 above) [^4]: (4 above)