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
You describe the change. Create a request, or ask your Vigilbase team or Vigil. The request starts as Needs scoping.
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.
The plan is approved. Vigilbase always confirms the plan internally. Depending on your approval policy, your documented request is enough, or your designated approvers must approve the exact plan.
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.
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
Click New request. The Request a change dialog opens.
Choose the Service. For example Cloudflare, NinjaOne or Afi.ai. Choose Other integrated service if yours is not listed.
Add a Title. At least 5 characters.
Fill in What should change? Describe the current behaviour, the result you want, the affected resources and your preferred timing.
Add a Reference (optional). For example an email, a Slack thread or an existing ticket.
Click Create change request. One opens the new request.
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:
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.
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.
Click Save approval settings.
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.
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.
Sign in as a designated approver, with the email address on the approval list.
Read the plan, including impact and rollback.
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.
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.