Key concepts

Understand the definition, the execution, and the evidence before building a larger automation.

One demonstrated task produces several related objects. Understanding the difference helps you change the right thing: edit a workflow to affect future work, inspect a run to understand one result, and open its session to see what happened in the browser.

Follow the guide-review example

The example task opens a documentation guide and returns its URL, title, and first three headings. Its workflow describes how to do that. The input Guide name changes between requests. A run is one attempt using a particular guide name.

Object	What it contains	Example
Workflow	Reusable inputs, task instructions, connections, and settings	Explore a guide
Version	A persisted snapshot of the definition and versioned metadata	The revision that adds a guide-title parser
Run	One execution's resolved inputs, status, events, and output	Review SOP document and screenshots this morning
Session	The browser or desktop environment for authoring or execution	The live browser shown while that run opens the guide
Trace	Recorded actions and evidence from a session	Open docs, click the guide link, read headings, capture the page

A workflow can have many versions and many runs. Changing today's instructions does not rewrite yesterday's recorded result. Run with the same data creates another execution from a past run's input values; it does not resume or undo that past run.

Understand the blocks in the graph

An agent task block describes an outcome and the instructions to reach it. The runtime agent chooses browser or computer actions while executing. It is more than a fixed list of click coordinates: it can inspect the current page and ask for help when the expected choice is missing.

An input node collects declared values. A parser transforms supplied text or documents into named structured fields. In the example, the operator supplies guide_name, and the parser resolves requestedGuideTitle for the browser task.

Variables panel showing the launch guide name and the parser's resolved guide-title field

The supplied value and the parsed value have distinct names because they enter the procedure at different stages.

A variable carries a named value between steps. A branch selects a path based on a decision. A trigger describes when new work starts, such as a matching email or schedule; it is not an ordinary browser action in the procedure.

When troubleshooting, inspect the value at the stage where it became wrong. If the parser resolved the wrong guide title, repeatedly adjusting the later click instruction will not fix the input interpretation.

Know what Save changes

Draft normally means that authoring has not produced a compiled graph. A save carrying a valid graph makes the workflow saved and runnable, unless it is explicitly kept as a draft or incomplete trigger configuration blocks promotion.

Enabled means new launches are accepted. Disabled preserves the definition and history while pausing new launches. Disabling does not stop a run that is already active.

Editor changes autosave as versions. Editing an enabled workflow does not create an unpublished copy: subsequent launches can use the saved change. Disable first if automated launches must pause during a revision. Browser/computer workflows have no separate Publish step; Agents is a separate builder with a draft/publish lifecycle.

Distinguish procedure from evidence

The SOP is an editable written view of the graph. Its instructions map to the workflow's fields, so editing them changes the definition. The attached screenshots are evidence of recorded states; they help a reader recognize the page and target.

SOP with an editable instruction and a recorded documentation-page screenshot

The text defines what to do. The screenshot illustrates the recorded state relevant to that instruction.

A screenshot from authoring is not a live view of today's run. After a large instruction change, review the attachment or re-match evidence so the procedure does not show an obsolete target. SOP document and screenshots explains attachment, editing, and stale evidence.

Decide where data belongs

Kind of information	Where it belongs	Why
A guide name, customer reference, or date that changes per request	Launch inputs	Each run should receive its own value.
A normalized field or result from an earlier step	Variables / declared node output	Later steps need the resolved value.
A reusable checklist or operating reference	Datastore	The same reference can support multiple runs.
A request-specific PDF or spreadsheet	The run's supported attachment/file input	It belongs to that request.
A login password or reusable authentication secret	Passwords, referenced by `#key`	Operators should not paste it into ordinary input fields.

Use Data and files for concrete examples. Then follow the quickstart to see a demonstration become a saved workflow and a verified run.

Was this page helpful?