From launch to completion
Starting a Play returns a public run ID before the workflow necessarily finishes. The run retains its admitted code snapshot. Later edits or publication do not change that execution. The primary run lifecycle distinguishes active work from terminal outcomes:
Waiting can be part of the design, such as a human approval. An error, a
stalled operation and a deliberate wait need different responses. Status,
recent activity and failure details help distinguish them.
A caller can wait synchronously or return while the run continues. Closing an
agent chat or reaching a local polling timeout does not cancel the remote run.
Progress, graphs and row results
The Play graph shows the workflow’s steps and decisions. Run progress connects that graph to observed execution. A failed step helps locate a problem without requiring the entire workflow to be repeated. For row-oriented work, datasets connect input records, computed columns and row outcomes. A batch can contain successful rows, legitimate no-match results and failed rows under its configured failure policy. The run’s overall status does not replace inspection of those row outcomes. Run summaries stay compact. They provide counts, progress, dataset references and previews rather than every retained row. The web app can display dataset rows, and export retrieves a selected run’s retained data without starting new provider work. An export from an active run can be partial. A scalar result can require a full-result read. A dataset instead has its own row retrieval and export path. The returned dataset paths and export actions identify the relevant output, including datasets nested in the result.Result visualizations
The web app presents result tables, dataset cells, the execution graph and run activity. These views connect an output to the input and steps that produced it. For a chart of arbitrary result columns, an agent can export the saved rows and create a chart or report from that output. This reads existing work without executing the Play again. For example, a qualification run can support an accounts-by-segment chart and a summary of unresolved records. The chart needs the selected run and dataset, the complete exported population, and explicit filters. A preview contains only a sample. Visualize a saved result explains this workflow and how to keep the chart’s counts traceable to its source.Logs, events and failure details
Logs contain messages recorded during execution. Structured logs can include the authored step, severity and custom context. Events describe lifecycle and work outcomes, such as a run starting, a step failing or a saved result becoming available. The CLI and SDK support filtered reads, retained counts and summaries. These help answer questions such as which step failed or how many matching events occurred in a chosen window. Retention limits still apply. Some saved operation results are available through event payload retrieval. Those results can explain a provider response or failed call. They do not replace dataset export. Run logs and events documents the query and retrieval contracts. A completed run can contain failed rows or no usable match. A failed run can still have useful retained results. Acceptance rules determine which business outputs can proceed.Recovery and reruns
Recovering observation means reading the existing run again. A saved run ID lets a restarted application or agent inspect its status and retrieve its results. It does not submit another execution. Rerunning starts a new run. Where retained input and artifacts are available, the rerun path can use the original snapshot and supported input changes. The new run has its own identity and can perform new provider work. Durable execution can reuse completed work during recovery. Reuse across new work depends on freshness and the operation’s contract. An old run ID or a stable step name alone does not make a new run free or its external effects exactly once. If the initial submission response is lost before the run ID is saved, the caller must reconcile the uncertain launch before submitting again. The application integration guide covers launch intent, saved IDs and idempotent destination writes.Cancellation and independent children
An explicit stop request cancels a run when its business result is no longer needed. The server can confirm a stop immediately or accept cancellation while cleanup continues. An acceptedcancelling response requires observing the same
run until it reaches a terminal state.
Stopping a run does not undo an external write that already happened. It also
does not disable its schedule, webhook or upstream Monitor. Future work needs
the corresponding trigger or Monitor control.
Inline child Plays share the parent’s execution. Independently launched
deepline.runPlayAsync children have their own IDs and lifecycle. Already admitted
children continue after parent completion or cancellation unless separately
stopped. Their lineage helps callers inspect the related runs.
Usage and notifications
Usage answers what the run consumed, separately from whether its business result was useful. Empty results, failed work and pending settlement do not establish zero usage. Cost control explains per-run usage and workspace spending limits. Notification settings determine which supported Play outcomes reach a recipient. Rules can select all runs, scheduled runs, webhook-triggered runs or a specific Play. A failure rule can match each failure or a configured number of consecutive failures. Delivery timing, destinations and recipient preferences control notification delivery. A failed run does not promise email to every member, and failed dataset rows need their own inspection. See Workspace notifications for settings, supported destinations and delivery checks.Continue learning
- Run Plays and view results: start, inspect and export a run.
- Run logs and events: investigate retained activity.
- Integrate a Play into your app: recover caller state and apply results.
- Runtime API reference: exact status, output and stop contracts.