# Stopping a Process

> A process can either be stopped through **Soft Stop** or **Kill** commands.

A process can either be stopped through **Soft Stop** or **Kill** commands.

## Soft Stop command

The **Soft Stop** command marks the process in a **should stop** state. This state can be queried from the still executing workflow using the [Should Stop](https://docs.uipath.com/activities/docs/should-stop) activity. The workflow should explicitly handle this state and finish. The workflow does not automatically stop without handling the **should stop** state. See **REFramework** for a scenario that leverages **Soft Stop**.

The **Stop** command is designed for unattended automations and is available only in **Orchestrator**. In **Orchestrator**, the **Soft Stop** command is named **Stop**.

## Kill command

The **Kill** command first sends a **Cancel** request to the workflow. The workflow **Cancel** request is distinct from **should stop**.**Cancel** is a workflow signal that is automatically handled by the workflow. The signal causes the activities to cancel in cascade while allowing **Finally** blocks of the workflow to execute clean-up steps. If the **Cancel** signal does not stop the workflow in three seconds, the job is killed by forcibly stopping any running activities at any point in their execution.

The **Kill** command is designed for attended automations and is available in **Orchestrator** and in desktop clients and APIs such as **Assistant**,**Studio**,**RobotJS**. In Desktop clients, the **Kill** command is named **Stop**.

## The REFramework Process Scenario

[REFramework](https://docs.uipath.com/studio/v2022.10/docs/robotic-enterprise-framework) leverages the **Soft Stop** command.

When a process is stopped, the block containing the error logic is skipped and the final block is executed. This causes the values for the `BusinessError` and `SystemError` to stay `null` and the overall process status is considered successful. The behavior described is intended.

### Try-Catch Scenario

During a [Try-Catch workflow](https://docs.uipath.com/activities/docs/try-catch), when a process is stopped, the transaction status can show as successful when it actually did not complete.

### Cancelling a Process

If the execution is in the **Try** or **Catch** block when the **Cancel** command is received by the **Robot**, it skips to the **Finally** block which checks for any errors. If no errors are found, then the **Finally** block thinks the execution completed successfully as there are no failure events (they are blank).

### Killing a Process

If the execution is in the **Try** or **Catch** block when the **Kill** command is received by the **Robot**, it first tries to **Cancel** the process, skipping to the **Finally** block. If the logic inside the **Finally** block is not finished in maximum 30 seconds since receiving the **Cancel** command, the whole execution is killed and the overall process is successful in the logs as no errors were recorded in the **Catch** block since it was skipped.

### Avoiding False Positives

* Setting the Process status to `Successful` should be done only inside the **Try** block, after the Business Logic is completed.
* Setting the status to `Failed` should be done only inside the **Catch** block, after the error handling logic is completed.
* In the **Finally** block, there should be only cleanup logic present, since it is executed no matter if the execution was successful or not.

## Ensure error logic is executed

If the block that contains the error logic is skipped, the values for `BusinessError` and `SystemError` stay `null` and the overall process status is considered `successful`, as no errors were recorded.