Using LevelFour
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.
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 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.
- The member opens the saving, picks an implementation method, and selects Request approval. The button then reads Pending admin approval.
- The saving moves to the Needs Approval tab, which only admins see. The dot on that tab pulses while requests are waiting.
- The admin opens it. Requested by names the member, and their method is already selected: approve to keep it, or pick another.
- 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.
Access grants
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 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.
From other surfaces
- The MCP server queues a rollout with
start-rollout, lists waiting requests withlist-approval-requests, answers one withrelease-rollout, and reads a step's output withget-execution-logs. See Tools l4 rec executerequests execution from a terminal