> ## Documentation Index
> Fetch the complete documentation index at: https://developer.kodexa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Approval Steps

> Model explicit approval gates in Activity Plans with APPROVAL steps that pause processing until an authorized person or role approves the next move.

`APPROVAL` steps model an explicit authorization gate in an Activity. Use them when the process must pause until an authorized person or role approves the next move.

For production review work today, the most common pattern is still a `CREATE_TASK` step backed by an approval Task Template and Data Form. Use `APPROVAL` when you want the Activity Plan to express the approval gate directly.

## When to Use APPROVAL

Use `APPROVAL` for authorization gates such as:

* Manager approval for invoices above a threshold
* Compliance approval before a covenant result is finalized
* Supervisor approval before a claim is accepted
* Credit approval before a lending packet advances
* Operations approval before data is posted to a system of record

Use `CREATE_TASK` instead when the approver needs a full review surface, document correction, multiple fields, or a rich Data Form.

## Basic Shape

```json theme={null}
{
  "slug": "manager-approval",
  "kind": "APPROVAL",
  "dependsOn": ["analyst-review:approved"],
  "config": {
    "approverRole": "finance-manager",
    "approvalCriteria": {
      "amountGreaterThan": 10000,
      "currency": "USD"
    }
  }
}
```

| Config key         | Description                                              |
| ------------------ | -------------------------------------------------------- |
| `approverRole`     | Role or responsibility that can approve the gate         |
| `approvalCriteria` | Business criteria that explain why approval is required  |
| `dependsOn`        | Prior Activity steps or actions that must complete first |

## Approval vs Review Task

| Need                                                         | Prefer        |
| ------------------------------------------------------------ | ------------- |
| Simple approve or reject gate                                | `APPROVAL`    |
| Reviewer edits extracted data                                | `CREATE_TASK` |
| Reviewer needs a Data Form                                   | `CREATE_TASK` |
| Approval must be visible as a step type in the process model | `APPROVAL`    |
| Existing production workflow needs rich human work           | `CREATE_TASK` |

## Common Pattern

```mermaid theme={null}
flowchart LR
    Extract["EXECUTION: extract"] --> Validate["SCRIPT: validate"]
    Validate -->|"within policy"| Post["BRIDGE_CALL: post"]
    Validate -->|"needs approval"| Approve["APPROVAL: manager approval"]
    Approve -->|"approved"| Post
    Approve -->|"rejected"| Reject["BRIDGE_CALL: reject"]
```

The approval gate is separate from the automation. The Activity can show exactly where authorization was required and what happened next.

## Criteria Design

Approval criteria should be understandable to the approver and auditable later.

Good criteria:

```json theme={null}
{
  "approvalCriteria": {
    "reason": "Invoice amount exceeds approval threshold",
    "amount": "{{steps.extract.mapped_output.total}}",
    "threshold": 10000,
    "currency": "USD"
  }
}
```

Weak criteria:

```json theme={null}
{
  "approvalCriteria": {
    "flag": true
  }
}
```

Approval criteria should explain the business reason, not just the implementation condition.

## Downstream Routing

Downstream steps should depend on explicit approval outcomes.

```json theme={null}
[
  {
    "slug": "manager-approval",
    "kind": "APPROVAL",
    "dependsOn": ["validate:requires-approval"]
  },
  {
    "slug": "post-approved",
    "kind": "BRIDGE_CALL",
    "dependsOn": ["manager-approval:approved"]
  },
  {
    "slug": "notify-rejected",
    "kind": "BRIDGE_CALL",
    "dependsOn": ["manager-approval:rejected"]
  }
]
```

Keep approval outcomes small and explicit. Most approval gates need only `approved`, `rejected`, and sometimes `needs-more-information`.

## Production Pattern With CREATE\_TASK

When the approval requires a full reviewer interface, model it as a Task:

```json theme={null}
{
  "slug": "manager-approval-task",
  "kind": "CREATE_TASK",
  "dependsOn": ["validate:requires-approval"],
  "config": {
    "taskTemplateRef": "manager-approval",
    "taskStatusSlug": "open",
    "taskData": {
      "approvalReason": "Invoice amount exceeds threshold"
    }
  }
}
```

This keeps the Activity-first model intact: the Activity owns the process and creates a Task when a person must act.

## Checklist

* The approval gate represents a real business authorization, not a generic pause.
* The approver role is clear.
* Criteria explain why approval is required.
* Downstream steps depend on explicit outcomes.
* Use `CREATE_TASK` when the approver needs a full review surface.
* Approval outcomes are included in audit and reporting expectations.

<CardGroup cols={2}>
  <Card title="Create Task Steps" icon="list-check" href="/guides/activity-plans/create-task-steps">
    Build rich human review and approval work.
  </Card>

  <Card title="Service Bridge Steps" icon="bridge" href="/guides/activity-plans/service-bridge-steps">
    Post approval results to external systems.
  </Card>
</CardGroup>