Change Management
ITIL change enablement for IT teams and the MSPs who co-manage them — with an approval trail you can hand to an auditor.
The problem
Most change control lives in a ticket note and a Teams thread. Someone patches a hypervisor on the Friday before year-end close. Nobody can say afterwards who approved it, whether anyone checked the maintenance calendar, or whether the rollback plan existed before the change or was written during the outage.
For an MSP it is worse. The client’s team makes changes to an environment the MSP is accountable for, and the first the MSP hears of it is the alert. The MSP has the responsibility and none of the visibility.
What Solidlio does about it
Solidlio records a change, works out who has to authorize it from its category, risk and the equipment it touches, and routes it to the right board. Approval requirements are frozen onto the change when it is submitted, so editing a rule later never rewrites the history of what was already authorized. Scheduling is checked against freeze periods and collisions before it is allowed. And because a managed client is a separate tenant, an MSP sees its clients’ changes and can be pulled into any individual one — by invitation, or automatically when a change touches equipment the MSP runs.
Capabilities
| Capability | What it does |
|---|---|
| Change authority matrix | Decide required sign-offs by category, risk, change type and affected assets. Require three signatures on security changes and one on routine ones. |
| Per-board quorum | Require a specific number of approvals, unanimity, or a named role such as the CAB chair. |
| Separation of duties | Stop a requester’s own approval counting toward the quorum on their own change. |
| Change Advisory Boards | Multiple boards per organization with chair, voting and advisory seats, and rules that route changes to the right one. |
| MSP engagement | Invite your MSP onto a single change, or escalate automatically when a change touches equipment they manage. |
| Freeze periods and blackouts | Block scheduling during year-end or peak trading, with recurring windows and audited overrides. |
| Conflict detection | Catch collisions with other changes and shared assets before the window is booked. |
| Emergency fast-track | Implement now, retro-approve against a deadline, with a mandatory review. |
| Maintenance windows | Named work windows that can suppress monitoring alerts for their assets while work is underway. |
| Post-implementation reviews | Automatic for emergency and failed changes, with AI-assisted drafting on Enterprise. |
| ITIL template library | Curated standard changes; MSPs choose what clients see and push their own. |
| Durable audit trail | Every decision, override and escalation recorded before the API responds. |
Built for MSPs and their clients
Change management in most tools assumes one company. Solidlio assumes two, and is explicit about which one holds each control.
| Organization | MSP | |
|---|---|---|
| Owns the change | Yes — raises, edits and cancels it | Can co-manage changes the client has made visible |
| Runs a CAB | Its own board | Its own board, separately |
| Controls MSP visibility | Yes — hidden, visible, or flagged for approval | No. Cannot widen or hide its own oversight |
| Invites the other party | Invites the MSP onto a specific change | Cannot invite itself |
| Escalation | Writes the rule that triggers it | Cannot decline a policy escalation |
| Configuration | Its own CABs, rules and policies | Can administer a client’s, as co-management |
An MSP’s own work is never filtered by client visibility settings — a recurring failure in multi-tenant tools where the provider ends up unable to see its own data.
How it works
- Raise — a technician records the change: what, why, risk, category, the equipment involved, and the implementation, rollback and test plans.
- Submit — Solidlio evaluates policy, resolves which approval rule applies, freezes that requirement onto the change, routes it to the right board, and notifies the approvers. Missing a required rollback plan stops it here.
- Authorize — each board approves independently. The change shows exactly what is outstanding: “2 of 3 approved, chair still required.” Any rejection is decisive.
- Escalate — if the change touches MSP-managed equipment, the MSP’s board is added as a second gate automatically.
- Schedule — the chosen window is checked against freeze periods and collisions. Overriding either requires acknowledging that specific objection, and is recorded against the person who did it.
- Implement and review — start, complete or fail. Failed and emergency changes automatically open a post-implementation review.
Compliance and audit
Every change carries a reconstructable authorization record:
- Who authorized it — each decision, with the approver, timestamp and any comment.
- Against which bar — the approval requirement is snapshotted at submission and retains the originating rule’s name even if that rule is later edited or deleted. The answer to “why was one signature enough?” survives the rule.
- What was overridden — policy violations and scheduling conflicts that were bypassed, with the person who bypassed them.
- Quorum at the moment of decision — how many approvals each board held and what remained outstanding.
Audit records are written before the API responds. A change that exists always has the trail that explains it — there is no window in which a change is committed but its authorization record is not.
Editions
| Capability | Starter / Essentials | Growth / Professional | Scale / Business | Enterprise |
|---|---|---|---|---|
| View changes and approvals | ● | ● | ● | ● |
| Full change lifecycle | — | ● | ● | ● |
| Tasks, comments, approvals | — | ● | ● | ● |
| Conflict detection and calendar | — | ● | ● | ● |
| Apply templates from the ITIL library | — | ● | ● | ● |
| MSP engagement and escalation | — | ● | ● | ● |
| Audit trail | — | ● | ● | ● |
| Change Advisory Boards | — | — | ● | ● |
| Approval rules (change authority) | — | — | ● | ● |
| Policies and freeze periods | — | — | ● | ● |
| Maintenance windows | — | — | ● | ● |
| Post-implementation reviews | — | — | ● | ● |
| Authoring and curating templates | — | — | ● | ● |
| AI-assisted review analysis | — | — | — | ● |
| Monitoring alert suppression | — | — | — | ● |
Managed clients without their own plan inherit their MSP’s tier.
Integrations
- Tickets and projects — link a change to the ticket or project that caused it.
- Assets — link affected equipment; asset management scope drives escalation.
- Monitoring — suppress alerts for a maintenance window’s assets (Enterprise).
- Calendar — scheduled changes and windows appear on the change calendar.
- Notifications — in-app and push alerts for submissions, approvals, outcomes and escalations.