Skip to main content
Version: 2.5

Form Runtime Debugger

The Fluent Form Runtime Debugger examines a rendered form with its current data and context. Use it when a field has an unexpected value or validation state, an effect changes another field, or the form cannot be submitted. The Form Logic Editor shows the configured relationships; the runtime debugger shows what happened in this form instance.

Open the debugger​

  1. In the avatar menu, expand Diagnostics and turn Debug on. This control requires the Toolbar.FluentDebugger privilege.
  2. Open the form you want to investigate. A round code button appears on the form while Debug is on; click it to open the debugger.
  3. Reproduce the issue after opening the form so the effect history contains the relevant interaction.

The debugger has two tabs: JEXL console for evaluating an expression in the current form, and Diagnostics for the current state, explanations, and recent effect runs.

Diagnose a live form with an AI coding agent​

An AI coding agent can inspect the same live form through a temporary, read-only diagnostic connection. This is useful when you can reproduce a problem but do not yet know which field, rule, effect, or request caused it. You normally provide only the URL of the open form and a question.

The connection is available only when both conditions are met:

  • the AI chats user parameter (aiChats) is enabled;
  • the user has the effective Toolbar.AiChat privilege.

If an administrator has just changed the privilege, refresh the authentication token or sign out and in again. The ordinary visual Runtime Debugger remains a separate feature controlled by Debug and Toolbar.FluentDebugger.

How to use it​

  1. Open the affected form in a signed-in browser tab and reproduce the issue.
  2. Give the agent the form URL. If your tool can bind an existing browser tab, tell it to use that tab so it keeps your authenticated form state.
  3. Ask one focused question. The agent uses a ten-minute inactivity lease that is renewed by each successful diagnostic read, reads the smallest relevant evidence set, and detaches when done.
  4. Review the answer in four parts: observed runtime state, supporting rule or failure evidence, remaining unknowns, and the narrowest next step.

Example questions:

On this form, why is the "Installation date" field hidden?
Why is Submit disabled? List only controls that are confirmed blockers.
After I changed Service type, the Address field kept its old value.
Which recent effect ran, what did its condition do, and which fields changed?
Inspect the mounted inner form for Contact details. Is E-mail required at
runtime, and which authored rule controls it?

Data and safety boundaries​

The connection can read bounded diagnostic summaries: form identity and lifecycle, element labels and schema paths, effective visibility and validation state, validation error keys, authored rule pointers, recent effect outcomes, and limited request outcome metadata. Authored schema is size-limited and sensitive keys are redacted.

It does not expose raw field values, raw errors, request URLs, query parameters, headers, request or response bodies, or transient effect contexts. It cannot change a value, click an action, submit the form, or execute arbitrary JavaScript through the diagnostic tools. If reproducing a problem requires a form change or another business action, authorize that interaction explicitly.

Agent-only diagnostic collection is in memory and enabled by the temporary attachment; the visual debugger can maintain its own in-memory diagnostics under its separate controls. Removing either aiChats or Toolbar.AiChat immediately removes agent discovery and ends the active attachment. A retained tool reference is rejected after access is revoked.

Evidence limits

An authored rule shows what can influence a field; it does not by itself prove which runtime input made the rule true. Likewise, request evidence confirms method, status, outcome, timing, and correlation—not payload content. A good diagnosis states these gaps instead of guessing.

Choose the scope​

The scope bar starts at Whole form. Use this to inspect the root form status and the complete recent effect history.

To focus on a node, click Select element by clicking and then click the rendered element, or search for it in Find element. Selection does not run that element's normal action. The selected element and its location in the form appear below the scope bar. Choose Whole form to clear the element scope.

Above the tabs, the selected node shows its current control status and validation error keys. A container can be invalid because of errors in child fields even when it has no error key of its own. The separate Whole form · Validation errors summary lists invalid controls in the form; click an item there to select it.

For a node bound to form data, Open in JEXL console inserts its path from the root, for example $value.customer.emails[0].address, and switches tabs. A layout node without a data path has no value-path action.

Root value versus selected value

Selecting a node changes the diagnostic scope. It does not replace the JEXL variable $value: $value always means the root form value. Use Open in JEXL console to inspect the selected node's value.

Read the diagnostics​

The Diagnostics tab checks the current form state and offers focused questions, such as why an element is hidden or what prevents submission. Refresh an explanation after changing the form; an older answer may refer to the previous state.

Effect history groups entries by recorded interaction. Expand a run to see the effects, their conditions, actions, outcomes, and paths they read or wrote. With an element selected, the list keeps effects directly related to its trigger, read, or write path, plus the upstream and downstream effects connected to them within the same run. A separate sibling branch is hidden. The count of shown and omitted effects follows the same selected scope. Switch to Whole form to see every recorded entry again.

Click an effect frame to inspect its captured context in the JEXL console. When available, this includes variables such as $event, $payload, $input, or $response from that frame. Copy for AI exports the displayed history as redacted JSON without raw form values; it follows the current scope. Clear effect history starts a fresh recording window.

Effect history is bounded. Older details can expire, and a path that was not recorded as an effect source cannot be inferred from the history. The displayed chain describes one recorded run; it does not prove causality across separate interactions or every read hidden inside an arbitrary expression.

Evaluate a value in the console​

The JEXL console evaluates against the current form. Enter $value for the whole form or a concrete path such as $value.customer.name for one field, then choose Evaluate or press Ctrl+Enter. You can select part of an expression and evaluate only that selection. Structured results use JSON syntax highlighting; plain text remains text. In a narrow debugger panel, the result fills the space below the expression editor. An effect frame selected in Diagnostics supplies its captured context to the console until you clear that frame selection.

For how effects are configured, see Form Effects and the Form Effects Reference.