Complexity

Overview

Complexity measures whether a workflow has grown past the size where one person can look at it and reason about every path through it. Like Naming, its findings are informational rather than urgent — a complex workflow isn't inherently broken. But complexity is the category most likely to cause findings in every other category, because a workflow nobody can hold in their head all at once is a workflow where a missing error handler or an unguarded write is easy to miss during review.

How this affects your score

Complexity is weighted 0.025, tied with Naming for the smallest weight in the total score. Findings scale with size: medium severity past 30 active nodes or a 20-hop path from a trigger, escalating to high past 60 nodes and critical past 100.

Worked example: a workflow with 65 active nodes triggers the high-severity node-count finding, scoring 100 − 15 = 85 on Complexity, contributing 85 × 0.025 = 2.125 points toward the total — again, a deliberately small effect on the overall score, since size alone isn't a direct production risk.

Findings

Active node count

Severity: medium (30+) → high (60+) → critical (100+). These thresholds are a proxy for "how much is actually happening in one place," not a hard architectural limit. A 35-node workflow doing one clearly-scoped job is a different situation from a 35-node workflow that's actually three unrelated processes glued together because they share a trigger — but node count is the cheapest available signal for "this might be doing too much," and it correlates with real difficulty in practice.

Example: a workflow started as a simple order-confirmation email and grew, over a year of incremental additions, into a 70-node process that also handles inventory updates, loyalty points, and analytics — none of which depend on each other succeeding.

Fix: split by responsibility. If two parts of a workflow don't depend on each other's success, they're a candidate for two separate workflows connected by an Execute Workflow call rather than one large one.

Longest path from a trigger

Severity: medium (20+ hops). A long serial chain is harder to reason about than a wide one, because every step downstream depends on every step before it having gone exactly right. This shape is also the one most likely to also trigger chain-failure findings in Reliability.

Example: a workflow chains 24 sequential steps from trigger to completion, each one depending on the previous step's output; debugging a failure requires tracing the entire chain to find where the data diverged from expectations.

Fix: pull long serial chains into a sub-workflow if they represent one logical step from the parent workflow's perspective — it turns a 20-hop path into a single node from the outside.

Recommended fixes

1. Split workflows by responsibility when they're doing more than one job that doesn't share failure dependencies.
2. Move long serial chains into sub-workflows to shorten the critical path as seen from the top level.
3. Use the node-count thresholds as a prompt to review, not a hard rule — a workflow just past 30 nodes doing one cohesive job may not need splitting; one at 25 nodes doing three unrelated things might benefit from it anyway.
4. Revisit workflows that keep growing — complexity findings tend to appear gradually, one added branch at a time, and are easy to miss without periodically checking back.

Related categories

• Reliability — long chains and wide fan-outs show up as chain-failure risk there too
• Naming — the other lightest-weighted category, also focused on long-term maintainability