Concurrent Runs

Available in Agent 1.1.75 and higher

Concurrent runs, also called parallel runs, allow the same TaskBot to run more than once at the same time on the same Desktop Agent. This is useful when a TaskBot handles independent jobs that shouldn't wait on each other, such as starting a separate run for each incoming webhook call.

What's a concurrent / parallel run? Two or more runs of the same TaskBot that are in progress simultaneously on the same Desktop Agent. Each run works independently and is unaware of the others; they simply overlap each other on the same machine.

Running different TaskBots at the same time is a separate concept and is enabled by default, without needing the Concurrent Runs setting.

How To Use It

Concurrency is configured per TaskBot, and is turned off by default. To enable it:

• Open your TaskBot's canvas.

• Click More options (the three dots) in the top right.

• Click Concurrent runs.

• Check the checkbox in the modal that appears.

Your Desktop Agent must be linked (logged in) for concurrent runs to work. Concurrent runs aren't meant to work on a Guest Agent, which is an Agent you haven't logged in to. A Guest Agent can only perform manual TaskBot runs, so you'll see an error if you trigger a second run for the same TaskBot while one is already in progress when using an unlinked Agent.

Things To Know

• This setting is only about one TaskBot running in parallel on the same Agent. Different TaskBots have always been able to run at the same time on one Agent, with or without this setting. Concurrent runs decide whether the same TaskBot can have more than one run in progress.

• Your hardware is the practical limit. ZeroWork does not cap how many runs of a TaskBot happen in parallel. What your machine can handle depends entirely on what your TaskBot does; a browser-heavy TaskBot typically exhausts resources far sooner than one that only moves data on the local machine.

• Persisted variables are shared between runs. Every concurrent run reads and writes the same variable values, so the last run to write a value wins. When you don't want that, turn off Persist value in the settings icon beside the variable. A non-persisted variable belongs to each run individually, so overlapping runs can't overwrite each other's variables. See Variables.

• Native tables and Google Sheets can be shared too. Parallel runs read, append, and update the same rows. This was already true of any table or sheet shared between TaskBots; concurrency doesn't change this.

• Device storage is shared by every run. Device storage keys belong to the Agent, not to a run, so all concurrent TaskBot runs on that Agent see the same keys and values.

• Both Default and Additional Agents support it. Concurrency requires a linked Agent, which means your account's Default Agent or any Additional Agent you've purchased and linked with its API key will work with this setting.

• The Run TaskBot block works alongside concurrency. A TaskBot started by another TaskBot follows the same rules: if the called child TaskBot has concurrent runs enabled, several parent TaskBots can run it in parallel. Manually stopping a parent run also stops the child runs it started with Wait until the TaskBot finishes enabled.

Run Behavior

• When concurrent runs are enabled and another run is triggered, both runs execute in parallel and independently of each other.

• When concurrent runs are disabled and another run is triggered while one is in progress, the second run is rejected with an error and does not start. The run already in progress continues.

• When a schedule fires while a run of that TaskBot is in progress, the scheduled run starts and overlaps the existing in-progress run. With concurrent runs disabled, the scheduled run is skipped and the run already in progress continues.

• When the Agent is a Guest Agent, concurrent runs do not work regardless of this setting. Scheduled and webhook-triggered runs don't run on a Guest Agent either, so the only runs available are manually triggered ones, and a second manual run is rejected while the first run is in-progress. Log in to the Agent to use concurrent runs.

• While any run is in-progress, a green badge beside the run button at the top of the TaskBot canvas shows how many runs are in progress, such as 2 running. It appears for a single run as well as for concurrent ones. Click the badge to expand it: each active run is listed with how it was started, the time it started, and a link to open its run details.

• When you stop one run from the badge, only that run stops. Each listed run has its own stop button; the other runs continue.

FAQ

1. What can start concurrent runs?

   Concurrency is about overlapping or running the same TaskBot in parallel, not about how each run was started. Any trigger can start a run, and a run from any trigger can run in parallel with a run from any other:

   • Manual runs. Click Run while a run is already in progress.

   • Webhook-triggered runs. Each call starts its own run.

   • Scheduled runs. A scheduled run is a run like any other. It starts even when a run of that TaskBot is already in progress, and likewise, while a scheduled run is in progress, triggering the same TaskBot manually or by webhook starts a second run in parallel with it.

Enabling concurrent runs changes how your existing scheduled run behaves. Prior to 1.1.75, a scheduled run was skipped if the TaskBot was already running, and the active run simply continued. With concurrent runs enabled, the scheduled run starts anyway and overlaps the run already in progress. If your TaskBot can take longer than its schedule interval, it will now overlap itself.