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

# Approval Workflow & Rules

> How a change goes from submitted to approved to executed — for both standard changes and update patches — and how to govern who must approve what.

import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components';

Approval is the heart of Change Management. Anything that will alter a system passes through a **human gate** before it runs — whether it's a hand-authored standard change or a batch of operating-system patches. This page covers that gate end to end and how to govern it with **approval rules**.

## The Gate, Step by Step

<Steps>
  <Step title="Submit">
    The author finishes the draft and **submits** it. The change moves to
    *Submitted* and the matching [approval rule](#approval-rules) determines who
    must sign off and how many approvals are needed.
  </Step>

  <Step title="Review and decide">
    Approvers open the change, review the justification, risk, window, and plan,
    and either **Approve** or **Reject**. The **Approvals** panel tracks progress
    live — for example *2 of 3* — and shows which rule is in force.
  </Step>

  <Step title="Approved">
    Once the required number of approvals is reached, the change becomes
    *Approved* and is ready to run.
  </Step>

  <Step title="Execute — the two paths">
    A **standard change** is started explicitly with **Execute** (Approved →
    Executing), and the agents run the steps. An **update patch** needs no manual
    trigger — it **installs automatically inside its scheduled maintenance window**.
  </Step>

  <Step title="Closed and audited">
    The change finishes as *Completed* (or *Partial* / *Failed*), and the whole
    decision trail is recorded in its history.
  </Step>
</Steps>

### Approving and rejecting

* **Approve** records your decision against your user. When the change reaches the required number of approvals, it advances automatically.
* **Reject** ends the approval flow — the change moves to *Rejected*. You can attach a **reason** so the author knows what to fix; they can then edit the change (which returns it to *Draft*) and resubmit.

<Note>
  Every approval and rejection is attributed to the user who made it, with a
  timestamp, and appears in the change's **Activity** history — so the record
  answers "who approved this, and when?" on its own.
</Note>

## The Two Execution Paths

The approval gate is identical for both kinds of change; only what happens *after approval* differs.

<CardGroup cols={2}>
  <Card title="Standard change — you Execute" icon="play">
    After approval, a person clicks **Execute** to start the change. This keeps a
    human in control of *when* the work begins, even after sign-off. The agents
    then run the implementation steps from the Workspace, and the rollback plan is
    on hand if it's needed.
  </Card>

  <Card title="Update patch — runs in the window" icon="clock">
    Approving a patch group **authorizes the agent to install it in the next
    maintenance window**. There is no manual Execute — the rollout begins when the
    window opens and progresses item by item. Approving is recorded under your user.
  </Card>
</CardGroup>

<Tip>
  For patches, approving is the commitment. The confirmation is explicit: *"This
  authorizes the agent to install this group's updates in the next maintenance
  window."* Until then, the pending-patches view is read-only and installs nothing.
</Tip>

## Approval Rules

By default, a change needs **one approval, and the requester may approve their own change**. That's fine for a small team, but most organizations want stronger governance. **Approval rules** let you define, per [context](/documentation/get-started/concepts#how-your-account-is-organized), exactly who must approve which changes — a policy that's evaluated automatically whenever a change is submitted.

A rule is made of:

| Setting               | What it does                                                                                                                                             |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**              | A label for the rule.                                                                                                                                    |
| **Change type**       | Which changes the rule applies to — **standard**, **normal**, or **emergency**. Leave it empty to apply to **all changes**.                              |
| **Minimum approvals** | How many approvals are required before the change can advance.                                                                                           |
| **Named approvers**   | An explicit list of users who may approve — only they count toward the minimum. Empty means **any approver**: anyone allowed to approve in that context. |
| **Active**            | A rule can be turned on or off without deleting it.                                                                                                      |

When a change is submitted, Myrmex finds the matching rule (by the change's type, preferring a rule named for that type over a catch-all) and applies it. The **Approvals** panel then shows the rule in force and the progress toward its minimum — for example, *min. 2*.

<Note>
  Rules are a policy layer, not a bottleneck: if no rule matches a change, the
  **default** applies — 1 approval, and the requester may approve. Removing a rule
  simply falls its changes back to that default.
</Note>

### Managing rules

Open the **Approval rules** view from Change Management to create, edit, enable/disable, or delete rules. Managing rules is a governance action, separate from approving individual changes — it's gated by the `gmuds.admin` permission.

<Warning>
  Deleting a rule doesn't block anything — changes in its scope fall back to the
  default policy (1 approval, requester may approve). If you need stricter control,
  disable a rule rather than leaving a gap, or replace it before removing it.
</Warning>

## Who Can Do What

Change Management is governed by a dedicated set of permissions, so you can separate the people who *author* changes from those who *approve* them and those who *govern the rules*:

| Permission      | Grants                                               |
| --------------- | ---------------------------------------------------- |
| `gmuds.read`    | View changes, their steps, and the approval rules.   |
| `gmuds.create`  | Create new change requests.                          |
| `gmuds.update`  | Edit changes, submit for approval, and manage steps. |
| `gmuds.approve` | **Approve or reject** submitted changes.             |
| `gmuds.delete`  | Delete changes.                                      |
| `gmuds.admin`   | **Administer the approval rules** (governance).      |

<Tip>
  Grant `gmuds.create` / `gmuds.update` to the engineers who plan changes, reserve
  `gmuds.approve` for change owners or a change-advisory board, and keep
  `gmuds.admin` with your governance team. Together with **named approvers** on a
  rule, this gives you clean separation of duties. See
  [Access control](/documentation/management/access-control).
</Tip>

## Related

<CardGroup cols={2}>
  <Card title="Change Management overview" icon="clipboard-check" href="/documentation/change-management/overview">
    The module, the two kinds of change, and the full lifecycle.
  </Card>

  <Card title="Patch & Update Management" icon="download" href="/documentation/agent-endpoint-security/patch-management">
    Consult pending updates and approve the patch schedules the AI proposes.
  </Card>
</CardGroup>