> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/build-automations/debug-and-stop-response.md).

# Debug an execution and configure its final response

Find the first action that behaves differently from your expectation, then check the response received by the caller. Debug controls inspect a run; the **Stop Action** configures how a response-capable Hyperflow finishes.

## Before you start

Use a test record, the intended Hyperflow version and an authorized application connection. Review external changes made by every action before the point you intend to debug. A partial run can still create records or send messages.

## Choose the controls available in your builder

In the Dublin editor, use **Run Hyper Flow** and **Inspector**, then inspect the execution log. Follow [error handling and debugging](/userguide/operate-and-troubleshoot/handle-errors-and-debug-a-flow.md) for error configuration.

Some builder versions expose a separate **Debug** bug icon. Where that control is available:

1. Select the bug icon to enable Debug. The builder displays debug markers on actions and a console below the flow.
2. Select an action's marker when you want to run up to that action. Without a selected action, the documented Debug path runs the whole flow.
3. Select **Run** and inspect each action's indicator. In this interface, green indicates execution without an error; red identifies an error to inspect.
4. Open the error indicator and compare the action's input and returned result with your expected values. Use the console filters to focus the result.

If the separate Debug controls are absent, use the Dublin run/Inspector path rather than looking for an older icon.

### Worked example: inspect the result passed to Stop & Return

The Dublin Work Item editor exposes **Flow - Stop & Return** as an action on the canvas. Inspect this action's own Result field and runtime input when diagnosing a return value.

The request-summary test first produced the expected String Assign text, but its Stop & Return runtime input contained `result: "false"`. The input also contained response status `"200"`. This is why checking a status value alone is insufficient: compare the action's result, data and overall execution context.

1. Open the relevant execution, select **View All Logs**, and open **Flow - Stop & Return**.
2. Fetch its input/output values and read **Input**. Confirm the `result`, `responseStatusCode`, `responseType` and `responseData` actually supplied to the action.
3. In the development Work Item, select **Yes** for **Result**. For the local example, use response status `200`, body type `text/plain` and the mapped `request_summary` value.
4. Save and release the corrected version. Run that version explicitly, then inspect its Stop & Return input again.

<figure><img src="https://3857940684-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJcSHU5jP5GABQrGmWvW2%2Fuploads%2FXIlYw8IbPVUz4xsI2qZg%2F22-return-yes-config.jpg?alt=media" alt="Stop &#x26; Return configured with Result Yes, response status 200 and the request_summary mapping."><figcaption></figcaption></figure>

The captured `v1.0.1` manual run completed successfully. Its Stop & Return input was displayed with the following values:

{% code collapsedlinecount="10" %}

```
result: "true"
responseStatusCode: "200"
responseType: "text/plain"
responseData: "REQ-DEMO-001 | VPN access | Maya Chen"
```

{% endcode %}

<figure><img src="https://3857940684-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJcSHU5jP5GABQrGmWvW2%2Fuploads%2FoJjL0dHoGU6WSSeid2C7%2F28-return-true-runtime.jpg?alt=media" alt="The corrected Work Item runtime input, showing result true and the expected request summary."><figcaption></figcaption></figure>

The editor states that the body response applies to API-triggered flows and is ignored for non-API triggers. This manual test verifies the action inputs and successful completion; it is not a captured external HTTP response. Test the actual API caller before documenting its response contract. See the [complete Work Item example](/userguide/service-automation/create-work-items-and-pin-released-versions.md) and the [Service Case diagnostic](/userguide/operate-and-troubleshoot/read-service-case-status-and-result.md) for the original service-run context.

## Configure the Stop Action

For a trigger that supports a caller response, open the Stop Action and select the required response type:

| UI response type | Payload          |
| ---------------- | ---------------- |
| No Data          | No response data |
| Application/Json | JSON             |
| Application/XML  | XML              |
| Text/Plain       | Plain text       |
| Text/XML         | XML text         |
| Text/HTML        | HTML             |

Set the content expected by the consuming application. Response support depends on the selected trigger; a webhook acknowledgement and a synchronous API result are different contracts. See [webhooks, API rules and responses](/userguide/integrations-and-api/webhooks-api-rules-and-responses.md).

## Check the result

Test one valid request and one controlled error. Check the caller's response type and body alongside the execution log. Use the action's **Stop & Response** error configuration when failure needs a distinct response. Keep credentials out of returned error text.

The Stop Action is not the same as the operator's **Stop Autom** control in Monitoring. Stopping an active execution does not undo changes already made in another system.