Inspect Node Results

Ensure to inspect each node by selecting a completed or paused node and reviewing its runtime data using the following order.

1. Output: Confirm what the node produced.
2. Input: Confirm what the node received.
3. Variables: Confirm the local values used during execution.
4. Context: Confirm what state and prior outputs were available.
5. Configuration: Confirm that the node is wired and configured correctly.

If the node uses expressions such as {{$context.$nodes.NODE_CODE.$output}}, validate the expression before interpreting the result. Confirm that there aren't any spaces inside the braces, the referenced node code exists, the referenced node ran before the selected node, and the property path matches the actual output shape.

LLM, Agent, and Multi Agent Nodes

For LLM, agent, and multi-agent nodes, inspect the following to verify that the model is receiving the correct inputs and producing valid outputs:

• The user prompt, the generated prompt, or the task instruction
• System instructions, if available
• The input context passed to the model
• The model output
• Token usage or duration metrics, when available
• Whether the output is valid for downstream use
• Whether chat history is enabled when the node depends on prior conversation

Here are some of the common issues encountered while debugging LLM, agent, and multi-agent nodes:

• Malformed JSON
• Missing fields
• Inconsistent intent labels
• Over-summarized output
• Output that doesn't match the downstream node's expected schema
• Model response that ignores the required business format

Decision Nodes: Switch and If Condition

For Switch and If Condition nodes, inspect the following to verify that the correct branch is selected based on the input data:

• The expression or condition being evaluated
• The actual input value used at runtime
• The selected branch or outcome
• The branch label shown on the canvas
• Whether the downstream path matches the user's request

Data, Tool, and Service Nodes

When creating run profiles for Business Object Function, External REST tool, Tool, Vector DB Reader, Vector DB Writer, RAG, Email, and Workflow nodes, make sure you cover the following scenarios:

• The selected object, tool, endpoint, index, workflow, or service configuration
• The input payload and parameter mappings
• Query attributes, filters, operators, or request body values
• The returned object structure, status, and error fields
• Empty, partial, or unexpectedly large result sets
• Whether downstream nodes expect the same data structure that the service returned

For retrieval nodes, also verify that the retrieved content is relevant to the user's request and that downstream summarization uses the retrieved content correctly. For writer or update nodes, confirm the operation, target identifier, and payload before allowing the workflow to continue.

Code, Set Variables, and Return Nodes

Verify that each node is configured correctly and produces the expected output.

• For Code nodes, inspect the input context, source code configuration, return type, and output structure. Confirm that the returned value matches the node's configured return type and any downstream schema expectations.
• For Set Variables nodes, inspect each variable's name, scope, type, and value. Confirm that downstream nodes read the intended variable from the correct scope.
• For Return nodes, inspect the return value and confirm that it's the intended workflow response payload. Use a Return node only when the workflow intentionally emits a specific structured result because not every workflow requires one.

Loop, Wait, Human Approval, and Parallel Nodes

• For Loop and While Loop nodes, inspect the collection or condition, each iteration's inputs and outputs, and whether the nested nodes receive the expected item or loop state.
• For Wait nodes, inspect the wait duration, loop-back target, message, and maximum iteration settings.
• For Human Approval nodes, inspect the channel type, approval or feedback settings, message template, actions, timeout behavior, and loop-back behavior.
• For Parallel nodes, inspect each branch outcome separately. Confirm that all required branches ran and that downstream nodes can handle both combined and branch-specific outputs.

Start, End, and Comment Nodes

• Start and End nodes are structural nodes. Use them to confirm where the workflow begins and where each execution path ends.
• Comment nodes are diagram-only annotations. They help explain the workflow canvas but don't produce runtime inputs or outputs.