.svg){kind=logo}
This article describes the warning messages that Orchestrator displays when editing an application. When you save the application, Orchestrator checks the canvas and displays a warning message if an issue is detected. Warning messages are non-blocking, so you can still deploy the application. However, unresolved issues may affect deployment time, runtime performance, or maintainability.
Canvas complexity
The user may see one of the following warning messages:
soft warning
This canvas is becoming complex (score: {score}). Complex canvases are harder to read and change safely, and may slow down deployment and promotion across environments. Main drivers: {cat_summary}. {suggestion}
critical warning
This canvas has reached a high complexity (score: {score}). At this level, deployments and promotions may take significantly longer or even require many retries to succeed, small changes carry higher regression risk, and the design becomes hard to reason about. Simplify before promoting to production. Main drivers: {cat_summary}. {suggestion}
The issue
Every canvas is translated into a configuration file before deployment. A larger and more complex configuration file results in slower deployments, increased runtime latency, and a higher risk of deployment failure. The complexity score estimates the size of the compiled file and identifies the main drivers of that complexity.
Note that the score is parameterized and may vary across environments
|
Score |
Warning Level |
Description |
|---|---|---|
|
Up to 6000 |
No warning |
The configuration is within acceptable limits. |
|
6000–7000 |
Soft warning |
The application deployed successfully but may experience issues with maintainability, readability and deployment. Review and optimize the highest-scoring categories. The margin between the soft and critical thresholds is intentionally narrow. Treat a soft warning as a prompt to take action. |
|
Above 7000 |
Critical warning |
The compiled configuration file is large enough to cause deployment failures and runtime degradation. Refactoring is required before deployment. |
|
Driver |
Recommended Action |
|---|---|
|
Set Field mapping rules |
A Set Field node contains many extra fields — each field generates a separate rule in the compiled file. Reduce the number of extra fields or split the node into smaller, focused nodes. |
|
Referent dependency lists |
The referent dependencies are the outputs from the first parent miniApp of a Set Field or Logging node. Shorten referent lists on Set Field nodes, or move shared reset logic into a dedicated sub-flow. |
|
Field assignments |
For MiniApps, Flows, Agents, or Re-asks with many input/output fields, every input and output counts as one assignment. Reduce the input/output field counts in MiniApps and Flows, or turn off Reset on intent where it is not needed. |
|
Condition routing |
Where branches merge back together, the routing logic from each branch is combined. Split such areas into sub-flows, reduce output fields on the nodes feeding the merge, or simplify the conditions on the edges. |
|
Structural trackers |
Each Set Field, Logger, Transfer, error-handler, and repeat-handler node adds one structural tracker. Consolidate nodes where possible. |
|
Condition fan-out |
Reduce the number of branches per condition node by grouping related cases or by chaining smaller Condition nodes. |
|
Anything else (Structural trackers, Reset on intent) |
Split heavy nodes into smaller ones, reduce field lists, or simplify the condition routing. |
Too many logging keys (KVPs)
The user sees the following message:
Warning: Your current logging keys exceed the recommended KVPs limit.
The issue
You are logging over 30 key-value pairs in a single Flow or Logger node. Such volume increases storage costs, complicates queries, and adds a minor per-call overhead.
How to fix:
-
Cut KVPs that nobody uses. If no dashboard or alert references a key, it doesn't earn its keep.
-
Group related values into one composite key instead of logging each separately (e.g.
account_summary = {balance, status, tier}rather than three keys). -
For audit-grade detail, push data to a downstream system rather than logging every field individually.
For more information on the KVPs, see Configure Settings of miniApps and Flows | Automated Logging of KVPs .
Subflow nesting depth
The user sees the following message:
Subflow 'My_Subflow' has a nested subflow chain that exceeds the recommended maximum depth (20). Please fix this issue.
The issue
A flow nested more than 20 levels deep is costly to load, and small changes deep in the chain affect everything above.
How to fix:
-
Flatten one or two levels: Select a middle Flow that does not need to exist independently and inline it into its parent.
-
Look for duplicated chains: If the same nested structure appears multiple times, extract it once and call it from the top.
Legacy NLU configuration
The user sees the following message:
This application uses legacy per-miniApp NLU configuration. Consider migrating to Global NLU for easier maintenance.
The issue
Each MiniApp in your canvas configures NLU separately. The Global NLU settings let you configure it once for the entire application, simplifying maintenance and serving as the foundation for future improvements.
How to fix:
-
Open the Global NLU panel for the application and set the languages, custom apps, and intents to use centrally.
-
Remove per-MiniApp NLU configuration from individual nodes; they inherit from the Global NLU automatically.
-
This migration changes only where the configuration resides; it does not affect the caller experience.