Who this is for. Anyone whose job should end early on a condition: a record that is not for this job, a lookup that found nothing, an endpoint that has answered. Afterwards you know exactly what a stop leaves behind. What follows was established by reading the platform's source, not by an executed test.

The Stop execution action

Two settings: Target Status, the status the run ends with (Success, Error or Skipped), and Delete batch, which deletes the run as it ends whatever the job's Batch persistence. A Stop is nearly always the only action in a condition branch: "if this is not for us, stop as skipped".

When it takes effect

  • At the top level of the job, the run ends as soon as the Stop has run.
  • Inside a condition branch, the run ends when the top-level action that contains it has finished. The actions after the Stop in the same branch still run. Put the Stop last in its branch.
  • Inside a loop, it ends only the current element, with the chosen status. The loop goes on to the next element; a sequential loop with Stop loop execution on error stops there when the status is Error. A Stop in a loop is the job's way to skip one row.

What a stop leaves behind

  • Every action that ran before it keeps its effects and its result. Nothing is undone: records stay written, requests stay sent, mail stays queued.
  • Top-level actions after it do not run and have no rows in the run log.
  • The run's status is the one the Stop named. With Batch persistence set to On Error, a run stopped as skipped or success is not kept, which keeps "not for us" runs out of the log.
  • The run's folder and its files go with the run if it is not kept, or if Delete batch is ticked.

If a job must not leave half its work done, put the checks that can stop it before the first action that writes anything.

What a web caller receives

In a synchronous web-event job, a Stop before any HTTP Response sends the caller the run itself as JSON, with HTTP 200 for a success stop and HTTP 500 for skipped or error. To end an endpoint early with a proper answer, use an HTTP Response with Stop execution ticked instead: it sets the reply and ends the run as a success. The same placement rule applies: actions after it in the same branch still run.

Trigger job

The other action that hands control elsewhere. It starts a Target job with Event data rendered as JSON; a synchronous target runs at once inside this run and its failure fails this run, an asynchronous target is queued and runs on its own. The pattern, with a two-job example, is Chaining one job to another.