> ## Documentation Index > Fetch the complete documentation index at: https://docs.corsa.finance/llms.txt > Use this file to discover all available pages before exploring further. # Closing Actions - Approve or Reject Transactions and Update Clients > Apply an outcome to a client or transaction when you resolve an alert or close a case, and learn which webhooks and audit entries each outcome produces. Closing actions let you decide what happens to the clients and transactions linked to an alert or case at the moment you resolve it. Instead of configuring post-closure workflows, you choose the outcome directly in the **Make Decision** dialog. ## How it works 1. Open an alert or case and select **Make Decision**. 2. Complete the **Alert Decision** (or **Case Decision**) step. 3. On the **Closing Action** step, choose an outcome for each linked client or transaction. 4. Review the **Impact Preview**, then select **Resolve** (alerts) or **Close** (cases). The alert or case is resolved and the outcomes are applied together. The Closing Action step appears when the alert or case has linked clients or transactions and the disposition allows an outcome. ## Available outcomes | Outcome | Applies to | What changes | | - | - | - | | **Approve** | Client | The account status becomes **Approved**. | | **Reject** | Client | The account status becomes **Rejected**. | | **Offboard** | Client | The account status becomes **Offboarded**. You must give an offboarding reason. | | **Approve** | Transaction | The transaction's **compliance decision** is set to `APPROVED`. | | **Reject** | Transaction | The transaction's **compliance decision** is set to `REJECTED`. | | **No Action** | Client or transaction | Nothing changes. The choice is still recorded in the audit log. | Which outcomes are available depends on the alert category, the disposition, and the current state of each client or transaction. An outcome that doesn't apply to a target is shown as a dash for it. > [!NOTE] > > An alert or case that targets transactions offers transaction outcomes. One that targets clients offers client outcomes. ## Transaction approve and reject Approving or rejecting a transaction records your compliance decision on it. It **does not change the transaction's execution status** (for example `PENDING`, `SUCCESS`, or `FAILED`). Execution status and compliance decision are separate. Your own systems decide what to do with the decision. For example, you can release a held payment when a transaction is approved, or keep it blocked when it is rejected. To act on decisions automatically, subscribe to the `transaction.updated` webhook. See [Closing action webhooks](#webhooks-and-audit-log). ## Several clients or transactions When an alert or case links more than one client or transaction, the Closing Action step shows a table: * Every row must have an outcome before you can continue. * Select rows with the checkboxes and use the buttons above the table to apply one outcome to all of them. A button is enabled only when **every** selected row supports that outcome. * Columns for outcomes that no row supports are hidden. * For alerts, an **AI Recommendation** column appears when the Triage Agent recommended outcomes. The recommendation is a suggestion. You make the final decision. ## Concurrent alerts and cases Approving, rejecting, or offboarding a client doesn't close the client's other open alerts and cases. If the client has other open items, the dialog lists them and notes that they remain open. ## Webhooks and audit log Closing actions use the existing webhook events. No new event types were added. | What you did | Webhook event | What it contains | | - | - | - | | Approved or rejected a transaction | `transaction.updated` | A change to the transaction's compliance decision (`complianceDecision`). | | Changed a client's account status | `individual_client.updated` or `corporate_client.updated` | A change to the client's account status. | | Chose **No Action** | None | Nothing changed, so no webhook is sent. | When a change comes from a closing action, the webhook includes `entityContext.alertId` or `entityContext.caseId` so you can tie it back to the alert or case. See [Transaction compliance decision](/webhooks/event-payloads#transaction-compliance-decision-from-closing-actions) for an example payload. > [!NOTE] > > `alert.closing_action_applied` and `case.closing_action_applied` are recorded in the audit log only. They are not delivered as webhooks. Every closing action decision is recorded in the audit log, including **No Action**. Each entry shows the outcome you confirmed, the default that was suggested, and whether you overrode it. ## Apply closing actions through the API When you resolve an alert or close a case with the API, pass a `closingActions` array on the update request: * Alerts: `PUT /v1/alerts/{alertId}/update` with `status` set to `RESOLVED`. * Cases: `PUT /v1/cases/{caseId}/update` with a closing status. Each entry in `closingActions` has these fields: | Field | Type | Description | | - | - | - | | `action` | `string` | One of `ACCOUNT_APPROVED`, `ACCOUNT_REJECTED`, `CLIENT_OFFBOARDED`, `TRANSACTION_APPROVED`, `TRANSACTION_REJECTED`, `NO_ACTION`. | | `targetKind` | `string` | `CLIENT` or `TRANSACTION`. | | `targetId` | `string` | The client or transaction ID (or reference ID) the action applies to. | | `defaultClosingAction` | `string?` | The outcome that was pre-selected before you confirmed. | | `defaultOverridden` | `boolean?` | `true` if you changed the pre-selected outcome. | | `offboardingReason` | `string?` | Required when `action` is `CLIENT_OFFBOARDED`. | | `offboardingReasonNote` | `string?` | Required when the offboarding reason is `Other`. | You can't apply closing actions to an alert that is already resolved. Actions must match the alert or case category, and the target must be linked to the alert or case. For the rest of the update request, see [Manage alerts and cases](/api/managing-alerts-and-cases). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.