While a Mind works, some steps wait on jobs that run in the background and can take minutes or hours. This page explains the controls that end such a step or the job behind it, and what each one leaves behind. What each card shows is described in Warehouse tool cards in chat.
While a step is still running, its card can carry a stop control. The label names what will be stopped:
A stop ends the step from the chat's point of view. Work that already runs on the server keeps running, and its result still lands in the chat when it finishes. The Mind is told that you stopped it, so it does not start the same step again by itself.
A stop does not end the job behind a wait. For that, use Abort run. When the request is accepted, a Stop requested toast confirms it. The controls disable and spin while a request is being sent, and on a phone they show only their icons.
Abort run ends the run behind a card: an ETL run, a workflow run, or a Lake run in a Lake Builder chat. It appears while a wait is still waiting, or while the platform reports the run as still going.
Abort ETL run {id}? or Abort workflow run {id}?; without a number it reads Abort ETL run? or Abort workflow run?.The dialog states the consequence:
After the abort, a toast reports the outcome:
Workflow run {jobId} aborted for a workflow run.Run aborted for an ETL run, or Run aborted (synchronize days restored to {n}) when the earlier synchronize days were restored.Roles and their permissions are described in Who can do what with Minds and Workflow permissions.
A refused stop or abort reports its reason. The common ones:
ETL job {id} is not running. The job finished before the abort arrived, so there is nothing to abort.Workflow run {id} is not running. The same, for a workflow run.Stop ends a step in the chat: a wait stops waiting, a sleep wakes early, and the Mind is told not to start the step again. Work already running on the server keeps going. Abort run ends the run itself: the ETL run or workflow run stops where it is. If you want the run to stop, use Abort run.
A Run transformation or Test run step hands its job to the runner and reports back, so there is no running step to cut short in the chat. End the run with Abort run while it is live. A Waiting for run step that waits on the same job does carry Stop waiting, which ends only the wait.
Three common reasons: the run behind the card is no longer live, your role lacks the abort permission, or the card is older than about two days and is no longer checked. A step that already finished or failed is settled and offers no controls.
The job stops where it is. With a truncate-insert pattern the table can be left partially loaded, so check the table before you use it. If the run was a backfill, the previous synchronize days are restored, and the toast names the restored value.
Only some steps carry stop controls: steps that wait on a job, a sleep, and steps that read over your data. This step is not one of them, so let it finish, or end the job it belongs to with Abort run if that appears.
The step had already finished, failed or been stopped when your request arrived, so there was nothing left to stop. The result in the chat stands. If a job the step started is still live, Abort run on its card can still end that job.
Aborting an ETL run needs Add/Modify Warehouse Objects; aborting a workflow run needs Execute Warehouse Workflow Objects; aborting a Lake run needs Execute Lake Workflow Objects. Without the permission, Abort run is not shown. Compare roles on Who can do what with Minds.
Yes, if the run is still going. When a wait gives up, the job can keep running; for recent steps the card keeps asking about the run and offers Abort run while it is live. The card's wording for that state is described in Warehouse tool cards in chat.
The request did not go through, and the run keeps going. The line under the toast names the reason, for example that the job is no longer running. Read it, then decide again from the card.