Run work in the background

Unity can continue an accepted assistant request while you navigate to another page, minimize chat, or work in another conversation. The request runs through a background execution service, and the conversation records its progress and results.

A background run can query data and save report changes. It is still working on the same report objects that manual edits and other conversations can change.

Start and follow a run

1. Submit a request in Data Chat.
2. Watch the conversation's active status and tool activity.
3. Navigate elsewhere if needed.
4. Return to the conversation to read its completion or error state.
5. Inspect the saved report result.

Build a new HTML detail page using the current model. Keep all existing
pages intact. Render and test the new page, and explain any unfinished
work when the run ends.

Closing a panel or navigating away does not itself request cancellation. If the request has not yet been accepted by the server, check its status before assuming a run exists.

Run states

A long-running query or browser render can make progress appear paused. The last visible tool and current run status help explain what is happening.

Use multiple conversations

A conversation permits one active request at a time. You can draft the next message while it runs, but cannot send another active request into the same conversation.

Different conversations can submit separate jobs. Execution capacity is bounded by worker configuration, so multiple accepted jobs are not a promise of unlimited simultaneous execution.

For independent tasks, use different targets: one chat can build a new page while another investigates a query. Concurrently editing the same visual or model definition can cause conflicts.

Stop a run

Use Stop in the active conversation. Unity requests cancellation and waits for the run to settle.

Stopping is separate from undo. A page or visual already saved can remain after cancellation. A query or mutation already in flight may finish before the stop takes effect.

If the stop request fails, the composer reports the failure and allows a retry. Inspect the run state rather than assuming the browser has killed the server process.

Recover partial work

1. Read the final status and activity.
2. Identify saved pages, visuals, and revisions.
3. Open the affected objects.
4. Continue the remaining work or restore specific changes through history.

Continue the interrupted build from the current saved page. Inspect
what exists and the last errors first. Repair the missing components
and render the page again before calling it complete.

This avoids creating duplicate pages based on the mistaken assumption that a stopped run saved nothing.

Handle simultaneous edits

Supported mutations can check an expected revision or current state. If another conversation or a manual edit has changed the target, the operation can report a conflict.

The assistant should inspect the latest state and preserve intervening work. A report-wide request is a sequence of saved operations rather than one all-or-nothing transaction.

Distinguish other background activity

CSV import processing has its own upload and validation lifecycle. Reference-file upload progress also differs from an assistant run.

Keep a CSV import dialog open during the browser transfer; later server processing can continue with it closed. See CSV imports. Use the file upload status for attachments, and wait until they are ready before submitting a message that needs them.

What completion means for HTML

The HTML build loop includes execution feedback and rendered previews. A completed save is only one step. If rendering or testing remains unresolved, the assistant should explain the gap.

Use HTML pages for verification controls and Change history for supported restoration.