# Route shape ## Introduction The **route** shape is used for cases where a process flow needs to split into multiple paths, based on a given set of conditions. Conditions are defined based on any fields found in the schema associated with your source data, so the scope for using routes is huge. To define multiple routes for your process flow you must: 1. Add a **route shape**. 2. Configure the **route shape** to add required routes and conditions. 3. Build the flow for each configured route by add [shapes](https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/process-flow-shapes) in the usual way. {% hint style="info" %} By default, multiple routes are processed in parallel when a process flow runs. {% endhint %} {% hint style="warning" %} If a route shape is added without route conditions, incoming data flows down ALL defined routes. {% endhint %} ## Accessing route shape settings ## Accessing route shape settings When you add a **route** shape to a **process flow**, the shape is added to your canvas with two placeholder route stems - for example:
To configure these routes (and add more if needed) click the 'cog' icon associated with this shape to access [route settings](#configuring-route-data-for-a-new-route-shape). ## Configuring route data for a new route shape Follow the steps below to configure **route data** for a **route** shape. **Step 1**\ Select a **source integration** and **endpoint** to determine where the incoming payload for the route shape is coming from - for example:
**Step 2**\ Select a **routing method** to determine what should happen if a payload record matches conditions defined for more than one route:
These options are summarised below: | Option | Summary | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Follow all matching routes | If a record matches defined conditions for multiple routes, send it for onward processing down all matched routes. | | Follow first matching route only | If a record matches defined conditions for multiple routes, send it for onward processing down the first matched route, but no more. |
Example To help understand how these options are used, consider an example where two routes are defined: * Route 1 is to send all orders where the `product_type` ordered is `shoes` to Warehouse 1 * Route 2 is to keep all orders where the `product_type` ordered is `boots` to Warehouse 2 But what should happen with an order that includes **both** shoes and boots? * If we choose to **follow all matching routes**, then this order will flow down both routes - ending up in the payload for Warehouse 1 and Warehouse 2. * If we choose to **follow first matching route only**, this order will only flow down route 1 - ending up in the payload for Warehouse 1.
**Step 3**\ Click the 'edit' icon associated with the first route:
**Step 4**\ Enter your required name for this route - it's a good idea to ensure this provides an indication of the route's purpose. For example:
**Step 5** If you intend to define multiple rules/filters for this route, select the required operator from the **filter logic** dropdown field:
* Select `AND` so all defined filters must apply for a match * Select `OR` so any one of the defined filters will result in a match {% hint style="info" %} If you only need to define one filter, just leave the default setting in place (it has no effect). {% endhint %} **Step 6**\ Click the **add new filter** button:
**Step 7**\ Filter settings are displayed:
From here, you can select a **field** (from the **data schema** associated with the **source endpoint** selected in step 1) - for example:
Alternatively, you can toggle the manual input option to ON and add syntax for [dynamic variables](https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/dynamic-variables):
{% hint style="info" %} The manual data path field supports [metadata variables](https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/dynamic-variables/metadata-variables). {% endhint %} **Step 8**\ Use remaining **operator**, **type** and **value** options to define the required filter. {% hint style="info" %} Presentation of the **value** field is dependent upon your selected **type**. When defining a **value**, you can include [payload](https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/dynamic-variables/payload-variables), [flow](https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/dynamic-variables/flow-variables), and [metadata](https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/dynamic-variables/metadata-variables) variables. {% endhint %} {% hint style="info" %} When a string filter **type** is selected, you have the option to select the **regex** operator and then define a regex value. This provides greater flexibility if you can't achieve the desired results using standard operators. `preg_match` is used for pattern matching. {% endhint %} The following data types are available when defining filters:
Variable typeVariable is defined and passed as...
StringA string value.
NumberA numeric value.
Specific dateA selected date - choose the required date/time from a date picker.
Dynamic dateA +/- number of seconds, minutes, hours, days, months, years to be matched relative to the current date.
BooleanA true/false value.
**Step 9**\ Use the **keep matching?** toggle option to choose how matched records should be treated:
Here: * If the **keep matching?** option is toggled OFF, matched records are removed from the payload before it moves on down the flow for further processing. * If the **keep matching?** option is toggled ON, matched records remain in the onward payload, and all non-matching records will be removed. **Step 10**\ Click the **save** button (at the bottom of the panel) to confirm these settings. The new rule is added for your first route - for example:
**Step 11**\ Repeat steps 6 to 10 to add any additional rules for this route. When you've added all required rules, click the **save**/**update** button at the bottom of the panel. **Step 12**\ Repeat steps 3 to 11 to configure the second route. **Step 13**\ Add any additional routes required using the **add route** button. Each time you add a new route, the canvas updates with an additional route stem from your route shape. **Step 14**\ Save your changes. ## What next? Having defined all required routes and associated conditions, the **route** shape on the canvas will have the corresponding number of route stems, ready for you to add shapes. For example:
Click the + sign for each branch in turn, then add the required shapes for each route flow. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.wearepatchworks.com/product-documentation/~/changes/J8IbZkP6ASUZu2oBhGi2/process-flows/building-process-flows/process-flow-shapes/standard-shapes/route-shape.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.