# Approvals and rollout

> Who can approve a saving, how a member asks an admin to, what runs after approval, and how to follow and retry a run.

Source: https://docs.levelfour.ai/savings-recommendations/approvals-and-rollout


## Who can do what

| Role   | On a savings recommendation                                           |
| ------ | --------------------------------------------------------------------- |
| Viewer | Reads everything. Cannot approve, reject, or request approval         |
| Member | Picks a method and asks an admin to approve with **Request approval** |
| Admin  | Approves or rejects, and answers members' requests                    |

[Members and roles](/account/members-and-roles) covers how roles are assigned.

## Two-person approval

A member can prepare a saving without being able to run it. An admin makes the call.

1. The member opens the saving, picks an [implementation method](/savings-recommendations/implementation-methods), and selects **Request approval**. The button then reads **Pending admin approval**.
2. The saving moves to the **Needs Approval** tab, which only admins see. The dot on that tab pulses while requests are waiting.
3. The admin opens it. **Requested by** names the member, and their method is already selected: approve to keep it, or pick another.
4. The admin selects **Approve Savings** or **Reject Savings**. After an approval, the drawer offers **Copy link** so the admin can hand the saving back to whoever set it up.

## After approval

An approved saving moves to **Pending** until it runs. The Implementation column on the **Savings** page follows it: **In Progress**, then **Completed** or **Failed**. Execution can take 12 to 72 hours to begin, and the page updates on its own when it does.

Once the change is applied, the saving moves to **Saved** and appears in [Savings Audit](/savings-audit).

> **Note**
>
> On an evaluation plan, a banner shows how many executions and days you have left.

## Access grants

[Automated Savings](/savings-recommendations/implementation-methods#automated-savings) acts through a grant: access scoped to one saving's actions and resources. The drawer shows where the grant stands.

| The drawer shows                                                  | Meaning                                                                                     |
| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Grant scoped, time-limited access that expires automatically.** | No grant yet. Select **Authorize in AWS** to create one                                     |
| **Waiting for approval**                                          | The stack is launched. LevelFour is waiting for AWS to report it and is checking the access |
| **Access granted**                                                | The grant is live. **Approve Savings** unlocks                                              |
| **Grant failed**                                                  | The stack or the check failed. Authorize again                                              |
| **Grant expired**                                                 | The grant ran out before the saving did. Authorize again                                    |

A grant for a saving expires three days after it is created. A grant for a [commitment renewal](/commitments/renewals) lasts 33 days, long enough to reach the end of the term it renews.

The **Activity** timeline records each grant: who requested the temporary access role, and whether it connected.

## Status & Logs

The drawer's third step follows the run.

| Field                     | What it shows                            |
| ------------------------- | ---------------------------------------- |
| **Triggered Via**         | The implementation method                |
| **Timestamp**             | When the run was triggered               |
| **Implementation Status** | Where the run stands                     |
| **Approved by**           | The admin who approved it                |
| **Execution Logs**        | Each step of the run and what it printed |

Until the run starts, the step reads **Execution hasn't started yet**.

## When a run fails

The drawer shows **Execution failed** with "A step did not complete." Open **Status & Logs** to see which step failed and why.

The implementation method list opens again. Keep the method or pick another, complete what it needs, and select **Retry**.

A Kubernetes change that regressed after its rollout stays failed, with no **Retry**, so its logs stay on the saving. The next change for that container arrives as a new recommendation.

## From other surfaces

* The MCP server queues a rollout with `start-rollout`, lists waiting requests with `list-approval-requests`, answers one with `release-rollout`, and reads a step's output with `get-execution-logs`. See [Tools](/mcp/tools)
* [`l4 rec execute`](/cli/commands/recommendations/execute) requests execution from a terminal