# Change requests

> Ask Vigilbase to change a managed service, review the exact plan, approve it, and set how your team signs off on changes.

Source: https://docs.vigilbase.com/one/requests/change-requests

Every change Vigilbase makes to your managed services, such as a DNS record or a Cloudflare setting, goes through a change request in Vigilbase One. The request keeps your original ask, the exact reviewed plan, approvals, the result, verification and a full activity history in one place.

Open **Change requests** under **Requests** in the sidebar, or go to https://one.vigilbase.com/change-requests. You need permission to read services to see it.

## How a change works

```mermaid caption="From request to verified change"
flowchart LR
  A[You request a change] --> B[Vigilbase scopes the plan]
  B --> C{Your approval policy}
  C -- Documented request --> E[Vigilbase executes]
  C -- Email review --> D[Your approvers approve]
  D --> E
  E --> F[Live state verified]
```

:::steps
1. **You describe the change.** Create a request, or ask your Vigilbase team or [Vigil](https://docs.vigilbase.com/one/ask-vigil). The request starts as **Needs scoping**.
2. **Vigilbase prepares a plan.** Your Vigilbase team scopes the work, with help from Vigil, into a plan: the exact target, its current and desired state, potential impact, rollback and verification. Preparing a plan changes nothing.
3. **The plan is approved.** Vigilbase always confirms the plan internally. Depending on your [approval policy](https://docs.vigilbase.com/one/requests/change-requests#set-how-your-team-approves-changes), your documented request is enough, or your designated approvers must approve the exact plan.
4. **Vigilbase executes it.** Before applying, One checks permissions, your policy and the live state again. If anything changed since the plan was reviewed, the change stops.
5. **The result is verified.** One reads the provider configuration back and, for DNS, checks public resolution. The result shows on the request.
:::

## Request a change

:::steps
1. **Click New request.** The **Request a change** dialog opens.
2. **Choose the Service.** For example **Cloudflare**, **NinjaOne** or **Afi.ai**. Choose **Other integrated service** if yours is not listed.
3. **Add a Title.** At least 5 characters.
4. **Fill in What should change?** Describe the current behaviour, the result you want, the affected resources and your preferred timing.
5. **Add a Reference (optional).** For example an email, a Slack thread or an existing ticket.
6. **Click Create change request.** One opens the new request.
:::

> [!NOTE]
> **New request** is available once your email address is verified. A request is not an approval: nothing changes until a plan is prepared and approved.

## Find a request

The list shows each request's **Request** title and short ID, **Status**, **Service** (or **To be scoped** before a plan exists) and when it was **Updated**. Use **Filter this page** to search by title, service or request ID, the **Status** menu to show one status, and **Refresh** to reload. The list shows 50 requests per page; use **Previous** and **Next** to move between pages.

## Statuses

| Status | Meaning |
|---|---|
| **Needs scoping** | Recorded; Vigilbase has not prepared a plan yet. |
| **Awaiting customer approval** | The plan is waiting for your designated approvers. |
| **Ready for execution** | Approved and waiting for Vigilbase to apply it. |
| **Executing** | Being applied now. |
| **Applied and verified** | Applied, and the provider configuration matches the plan. |
| **Awaiting DNS propagation** | Applied; public DNS has not shown the new answer yet. |
| **Verification failed** | Applied, but verification found a mismatch or stopped. Vigilbase reviews it. |
| **Failed** | The change could not be applied. |
| **Needs reconciliation** | The outcome is uncertain. Vigilbase checks the provider before anything else happens. |
| **Rejected** | An approver rejected the plan. |
| **Approval expired** | The approval window closed. Vigilbase must prepare a fresh plan. |
| **Rolling back**, **Rolled back** | Vigilbase is restoring, or has restored, the previous state. |
| **Rollback awaiting DNS propagation** | Rolled back; public DNS has not caught up yet. |
| **Rollback needs reconciliation** | The rollback outcome is uncertain and is being checked. |
| **Completed by operator** | A Vigilbase operator did the work by hand and recorded the evidence. |

## Read a request

Click a request to open it. The page shows:

- Your description and reference.
- The plan, once prepared: the exact target, expected current state, before and after values, **Potential impact**, **Rollback plan** and **Verification plan**. Some services have no automated operation; their plan says an operator performs the approved work by hand.
- **Approvals**: the **Internal confirmation** and the **Customer approval**. Under the documented-request policy, customer approval reads **Covered by the documented customer request.**
- **Verification**: whether the **Provider configuration** matches the reviewed plan, what **Public DNS** shows, and the **Last check**. After a change is applied, **Verify live state** checks again.
- **Activity**: every event on the request, with time and actor.

For changes completed by an operator, the page shows the operator's evidence. Vigil has not independently verified those changes.

## Set how your team approves changes

The **How your team approves changes** section at the bottom of the Change requests page sets your approval policy. Vigilbase always reviews infrastructure changes; the policy decides whether your team also approves each plan.

Owners and admins of your organisation with a verified email address can change it. Everyone else sees it read-only.

### Approval format

- **Approve by documented request**: a written request from your team is enough. Vigilbase still reviews the plan before anything changes. This is the default.
- **Approve by email review**: designated people receive the full plan, impact and rollback steps by email, then sign in to approve before execution.

### Approvers for email review

If you choose email review:

:::steps
1. **Choose who must approve.** **Any one approver** lets one person from the list approve. **Every listed approver** requires each person on the list to approve before the change can run.
2. **Pick approvers.** Tick people under **Linked people**: members with access to your organisation, or linked contacts. To add someone else, type their address in **Add another email** and click **Add**. You can designate up to 10 approvers.
3. **Click Save approval settings.**
:::

> [!IMPORTANT]
> Approvers must already have Vigilbase One access for your organisation. Invite them before saving if needed. Saving a new policy invalidates pending reviewed plans; Vigilbase must prepare and confirm them again.

## Approve or reject a plan

When a plan needs your approval, designated approvers get an email with the full plan, and **Home** lists it under **Waiting on you**.

:::steps
1. **Open the request.** Use the link in the email or on **Home**. The email link only opens the review; it does not approve or execute anything.
2. **Sign in** as a designated approver, with the email address on the approval list.
3. **Read the plan,** including impact and rollback.
4. **Click Approve change or Reject change.** Add an optional comment, tick the confirmation and click **Confirm**.
:::

After approval, a Vigilbase operator executes the approved plan. A reply to the email, or a statement in a chat, does not count as approval.

> [!WARNING]
> An approval request expires 72 hours after the plan is sent for approval. After that the plan can no longer be approved, and Vigilbase has to prepare a fresh plan for you to approve. The request page shows the expiry time while approval is pending.

## Rollback

If a change needs to be undone, Vigilbase rolls it back using the rollback plan you approved. A rollback restores the saved configuration only if the live resource still matches the change, and is verified like the original change. It cannot undo side effects that already happened, such as notifications or jobs the change triggered.