Overview
The comment node is a purely decorative annotation tool for
the flow canvas. It has no inputs and no outputs. It does not process any messages. Instead, it
serves as a visual label to document your flows, explain design decisions, mark sections, or leave
notes for other developers. Comment nodes support multi-line text and optional color coding for
visual organization.
Properties
| Property | Type | Default | Description |
|---|---|---|---|
| text | string | "" | The annotation text displayed on the canvas |
| color | string | "#ffffff" | Background color of the comment node |
Behavior
No Processing
The comment node does not receive, process, or send any messages. It is completely inert and has zero impact on flow execution or performance.
Visual Only
It renders as a text block on the canvas. The text appears both as the node label and in the info sidebar when selected.
Multi-line Support
The text field supports multiple lines, allowing detailed descriptions and structured notes.
Color Coding
Use different colors to categorize comments: red for warnings, green for completed sections, blue for documentation.
Example: Document Flow Purpose and Design
Place comment nodes at strategic locations to explain what each section of a flow does.
// Comment node at the top of the flow
{
"text": "SENSOR DATA PIPELINE v2.3\n\nThis flow collects temperature and humidity\nreadings from MQTT sensors, validates the\ndata, applies calibration offsets, and stores\nresults in InfluxDB.\n\nAuthor: Engineering Team\nLast updated: 2025-01-15\nSLA: 99.9% uptime required",
"color": "#4A90D9"
}
// Comment node near the validation section
{
"text": "VALIDATION RULES:\n- Temperature must be -40 to 85 (sensor range)\n- Humidity must be 0 to 100\n- Messages without deviceId are dropped\n- Duplicate readings within 1s are filtered",
"color": "#F5A623"
}
// Comment node near the error handling section
{
"text": "ERROR HANDLING:\nAll errors are sent to the central error\nhandler via Link Out. Critical errors\ntrigger PagerDuty alerts.",
"color": "#D0021B"
}Best Practices for Flow Documentation
Do
- Add a header comment to every flow with its purpose
- Document non-obvious design decisions and trade-offs
- Note external dependencies (APIs, databases, services)
- Include version numbers and change dates
- Use color coding consistently across all flows
- Mark sections that require special attention
Don't
- Over-document obvious nodes and connections
- Store sensitive information (passwords, keys) in comments
- Let comments become outdated and misleading
- Use comments as a substitute for clear node naming
- Clutter the canvas with too many small comments
- Forget to update comments when the flow changes
Suggested Color Coding
Blue
General documentation and flow descriptions
Amber
Important notes, configuration requirements
Red
Warnings, error handling, critical sections
Green
Tested sections, approved patterns