> ## Documentation Index
> Fetch the complete documentation index at: https://control-dev.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Review runs and approvals

> Inspect an agent workflow's run history, follow a run's events and audit entries, and decide on external-action proposals waiting for approval.

# Review runs and approvals

Every triggered occurrence produces a persisted run. External writes never execute directly; the agent files a proposal that a human approves or rejects. Both are visible in the Studio.

## Run history

Open the **Runs** view and select an agent to see its runs, newest first.

Each run row shows:

* **Status.** Queued, running, succeeded, or failed.
* **Started at** and **completed at** timestamps.
* **Trigger source.** Manual, schedule, Control event, or signed external event.
* **Error code and message** when the run did not succeed.

Selecting a run expands two lists:

* **Events.** A time-ordered stream of what the agent did during the run — tool calls, intermediate reasoning summaries, produced artifacts, and the final output.
* **Audit entries.** Governance-relevant records such as tool grants exercised, external-action proposals filed, and decisions recorded on those proposals.

Use the events list to confirm which Control tools the run invoked and to verify the agent's summary against the underlying data.

## Rerunning a workflow

To rerun the same instructions on demand, use **Run now** in the Builder. To have Control rerun on a schedule or event, configure the appropriate trigger. See [Trigger workflows](/product-docs/agents/triggers).

Occurrences and their runs are immutable. Editing the draft and publishing a new version does not change past runs; new triggers dispatch runs against the new version.

## Approvals view

The **Approvals** view lists external-action proposals filed by any workflow in the tenant. Each proposal captures:

| Field                   | Meaning                                                                                                                              |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Provider and action** | Which integration and action the agent wants to perform, for example `slack.post_message`.                                           |
| **Payload**             | The exact content to send. Fixed destinations configured on the tool are locked in and cannot change between proposal and execution. |
| **Proposal hash**       | A checksum over the payload the reviewer approves. Approvals are bound to this hash.                                                 |
| **Idempotency key**     | Ensures Control can safely execute the proposal at most once with the provider.                                                      |
| **Requester and time**  | The workflow run that filed the proposal and when.                                                                                   |
| **Status**              | Pending, succeeded, failed, or rejected.                                                                                             |

Proposals inherit tenant-level access controls. Any tenant member can open the view.

## Approve or reject a proposal

1. Open **Approvals**.
2. Select the proposal.
3. Read the payload and confirm the fixed destination (for example, `#finance-review`).
4. Choose **Approve** or **Reject**.

Effects:

* **Approve.** Control atomically claims the proposal for execution, sends the exact payload to the provider through the bound connection, and records the result. If the provider fails, the proposal is marked failed with a sanitized error message and can be retried by reconciling delivery.
* **Reject.** The proposal is closed as rejected. No provider call is made.

Approvals check the proposal hash, so a payload cannot be changed between review and execution.

## Reconciling provider delivery

If the provider call is interrupted or its response is lost, Control keeps the proposal in a claimed state and surfaces reconciliation controls in the Approvals view.

1. In the provider's own UI (for example, Slack), confirm whether the message was actually delivered.
2. Enter the provider's receipt (message ID or draft ID) in the reconciliation input.
3. Confirm **Delivered** or **Not delivered**.

Confirming delivery marks the proposal succeeded and records the provider receipt against the run's audit trail. Confirming non-delivery marks it failed so the workflow can re-propose if needed.

## Verify what actually happened

For every action the workflow took:

* The originating run in the **Runs** view lists the tool calls and the proposal filed.
* The proposal in the **Approvals** view shows the exact payload, the approver, and the provider receipt.
* The workflow's audit entries link the proposal to the run and to the trigger that produced the occurrence.

## Related tasks

* [Trigger workflows](/product-docs/agents/triggers)
* [Build and publish a workflow](/product-docs/agents/build-and-publish)
* [Connect Slack, Gmail, and event sources](/product-docs/agents/connections)