Reusing Logic in Node‑RED with Subflows

The problem: duplicated wiring

When building IoT dashboards you often find yourself wiring the same pattern over and over: an MQTT input node, a function node that does some calculation or filtering, and an output node such as email, Slack, or a database write. Copy‑pasting that set of nodes across many flows makes the project hard to maintain – a change in the function logic requires editing every copy, and it’s easy to miss one.

Thesis: subflows encapsulate repeatable logic

Node‑RED’s subflow feature lets you turn a group of nodes into a single reusable unit. You expose only the inputs and outputs you need, and you can configure the subflow’s behaviour with environment variables. Once saved, the subflow appears in the palette like any other node and can be dropped into any flow.

Creating a subflow

1. Select the nodes you want to reuse (e.g., MQTT in → function → SMTP out).
2. Right‑click the selection and choose Convert to Subflow.
3. In the subflow edit dialog, add an input node for each message you want to receive and an output node for each result you want to emit.
4. Optionally, define environment variables under the Environment tab; these become configurable when you drop the subflow into a flow.
5. Click OK, give the subflow a name, and press Deploy.

Worked example: temperature‑alert subflow

Suppose you have several temperature sensors and you want to send an email whenever the reading exceeds a threshold that may differ per deployment.

1. Build the core logic: MQTT in → Function (checks payload against a threshold) → SMTP.
2. In the function node, read the threshold from an environment variable:

// function node code
const threshold = flow.get('threshold') || env.get('TEMP_THRESHOLD') || 30;
if (msg.payload > threshold) {
    return msg; // pass through to SMTP
}
return null; // stop the message

3. Convert the three nodes to a subflow, expose one input (the MQTT message) and one output (the SMTP call). Add an environment variable named TEMP_THRESHOLD with a default of 25.
4. Save the subflow as Temperature Alert.

Now you can drag the Temperature Alert subflow into any flow that monitors a temperature sensor. Set the environment variable on a per‑flow basis (or leave the default) to adjust the threshold without opening the subflow.

Trade‑offs and limitations

While subflows improve modularity, they add an extra hop in the debug sidebar. When you step through a flow, you see the subflow as a single block; you must open the subflow to inspect internal node status, which can make tracing slightly less intuitive.

Version control also requires attention. A subflow’s definition is stored inside the flow JSON, but to share it between instances you typically export it (Menu → Export → Subflow) and import the resulting JSON file. Changes to the subflow’s internals require a redeploy of the parent flow, which may cause a brief interruption in a live system.

Practical verification

To confirm the subflow works as expected:

1. Create a test flow with an inject node set to emit a numeric payload (e.g., 22 and 28).
2. Connect the inject node to the Temperature Alert subflow, then connect the subflow’s output to a debug node.
3. Set the environment variable TEMP_THRESHOLD to 25 (either in the subflow’s default or override it in the test flow).
4. Deploy and trigger the inject node. You should see a debug message only for the payload 28, confirming that the internal function correctly compared the value against the threshold.

Export the subflow (Menu → Export → Subflow) and import it into a fresh Node‑RED instance; the imported subflow retains its environment variable definition and behaves identically, demonstrating portability.

Actionable closing

If you find yourself copying the same node chain across multiple flows, try converting it to a subflow. Start with a small, well‑tested piece of logic, expose the necessary inputs/outputs, and use environment variables for any values that might vary between deployments. Verify the subflow with a simple inject‑debug test, then roll it out to your production flows. The result is a cleaner, easier‑to‑maintain project with a single source of truth for reusable logic.