Running tasks

You start a task from the editor, follow it live in the web app and on the agent's screen, and find every run afterwards under Executions with its log, outputs and, when it failed, the details of why.

#Start a run

Open the task in the editor and click Run in the toolbar. The Run dialog opens, titled with the task's name.

Note: Agents run the saved task. If you have unsaved changes, save first (Ctrl+S): the editor reminds you with Save your changes first.

#What the editor runs

The editor runs what it shows:

• In your local workspace, the run uses your local copy (the dialog title ends with (local copy)). Tasks it calls with runtask also use your local copies where you have them, else their public versions.
• In the public workspace, the run uses the current public version.

Executions record which one ran: the history shows v3, Local copy of v3 or Local copy (for a task never pushed). Schedules always run the public version. See Versions and workspaces.

#Choose the agent

The Agent list offers:

• Any available agent (N online): the run goes to the first idle, online and approved agent.
• A specific agent. Each agent shows its status; agents that are offline, busy or not approved (Not approved) cannot be chosen.

When no agent is online, Run is disabled and the dialog says No agent is online. Start the Botream Agent on a machine first. For how agents are picked, see Agents.

Note: Agent groups are used by schedules. A run from the Run dialog goes to one agent or to any available agent.

#Fill in the inputs

If the task declares inputs (input --name:... --type:...), the dialog lists them under INPUTS with their type. Default values are filled in; required inputs without a default must be entered. Boolean inputs offer Yes (true) and No (false).

input --name:invoiceDate --type:datetime --required:true
input --name:maxInvoices --type:number --default:50 --required:false

Click Run to start.

#While it runs

The editor is covered by a small card saying Starting the task…, then which task runs on which agent, with the elapsed time:

• Cancel stops the task on the agent.
• Watch the live log opens the execution page.

When the run ends, the card closes and a notification shows the result. On the agent machine, the progress window shows the current command and lets someone pause or stop the run (see Agents).

Tip: To start at a later command, use Run from here in a block's menu, or Debug to stop at breakpoints. See Debugging.

#Execution history

Executions lists every run, newest first, and updates live. Each row shows:

Filter the list with Search tasks (task name), the status list (Any status) and the agent list (Any agent). Click a row to open the run.

Users with the See all runs permission (Admin and Developer by default) see every execution; everyone else sees only the runs they started.

#The execution page

The execution page shows one run:

• The task name (a link to the task for users with Edit tasks), the status and the version.
• Agent, Started (or Waiting for the agent), Duration (live while running) and Started by.
• Inputs: the values the run received.
• Outputs: the values of the task's output variables, once it has finished.
• Pause / Resume: shown while the run is going. A paused run waits before its next command; its status shows Paused, with the reason when the task paused itself.
• Stop: shown while the run is going; stops it on the agent. The execution ends as Stopped.

#Stopping and pausing from the task

Three commands next to runtask let a task stop or pause runs:

if --condition:"$orders.Count$ = 0"
    stoptask --message:"No orders today"
endif
pausetask --message:"Check the invoice in the ERP, then press Run" --timeout:600
stoptask --name:"Finance/Import" --output:stopped
pausetask --name:Export
resumetask --name:Export

Stopping, pausing and resuming another task's runs is recorded in the audit log, as are Pause and Resume in the web app.

#Live log

The log streams in while the task runs. Each line shows the time, the level (DBG, INF, WRN, ERR), the line number in the task (hover it for the command) and the message.

• Filter by level: All, Info + (info, warnings and errors), Warnings, Errors or Debug.
• Search in log keeps only matching lines.
• Follow keeps the newest line in view. Scrolling up pauses it; click Follow (or Latest for a finished run) to jump back to the end.

The log handles very long runs, with hundreds of thousands of lines.

Note: Passwords read from a vault are replaced with *** in log lines, error messages and outputs. Debug lines are kept only while Keep debug log lines is on in Settings.

#Failure details

When an error that no catch handles ends a run, the agent records what it saw at that moment. The execution page shows:

• The error message, with the Line number and the command that failed.
• The error type: Business rule (thrown by the task with throw: fix the data or the process, a retry would not help) or System error (the application, network or machine failed: a retry may work). See Error handling.
• Screen when the task failed: a picture of the agent's whole screen (all monitors). Click it to view it full size.
• Variables at the failure: the task's variables as a tree. Secrets are masked and long values cut.

Inside a runtask call, the details are those of the called task, where the error happened.

#AI failure analysis

On a failed run, AI failure analysis can explain what happened, the likely cause and how to fix it. Click Analyze with AI; the answer is kept with the run, and Analyze again asks once more. The model receives the error, the failing command, the last log lines and the variables, with passwords left out; the screenshot only when an administrator allows it. See AI features.

Warning: AI can be wrong. Check the analysis before you act on it.

#Dashboard overview

The Dashboard is the first page after sign-in and updates live. Choose the period at the top right: 7 days, 14 days or 30 days.

#Selector health card

The card counts what happened to the element commands of recent runs:

• Steps healed: steps where self-healing used a similar element.
• Saved by fallbacks: steps a fallback locator found.
• Failures prevented: runs that completed only because an element was healed or found by a fallback.
• Drifting: selectors whose element changed since the capture. Re-capture them before they break.
• Broken: selectors whose element was not found in their latest run.
• Healthy: element commands that found their element as captured.

Users with Edit tasks can click View report for the full Selector health page. See Finding elements reliably.

Users with the User role see a welcome page instead of the dashboard figures; see Users and roles.