Change Management

Last verified against the codebase: 2026-07-25.

---

What it is

Change Management is Solidlio’s ITIL change-enablement module. It records proposed changes to your environment, routes them to the right people for authorization, schedules them against a calendar that understands blackout periods and collisions, and keeps an audit trail of who authorized what.

It works for a single organization managing its own IT, and for an MSP co-managing changes across many client organizations.

---

Concepts

How a change is authorized

Change submitted
      │
      ├─ Approval rule resolved  ─────►  frozen as an approval requirement
      │   (category / risk / type / affected assets)
      │
      ├─ Routed to a CAB  ────────────►  approvals created for voting members
      │
      └─ Escalated to the MSP?  ──────►  MSP's own CAB also becomes a gate
                                          (if a rule requires MSP sign-off)

Change becomes APPROVED only when EVERY binding requirement is satisfied.

---

Roles and permissions

Solidlio’s role hierarchy is platform administrator > MSP administrator > MSP technician > organization administrator > power user > CUSTOMER`.

Approving is deliberately not role-gated. Authorization is by membership: you may decide an approval if and only if it is assigned to you. This lets a CAB seat a subject-matter expert below organization administrator — a power user DBA, say — and have their vote count. Anyone who is not the assigned approver is refused.

---

The change lifecycle

DRAFT ──submit──► PENDING_APPROVAL ──all sign-offs──► APPROVED
                          │                               │
                          │                            schedule
                          ▼                               ▼
                      REJECTED                        SCHEDULED
                                                          │
                                                        start
                                                          ▼
                                                     IMPLEMENTING
                                                          │
                                                     complete
                                                     ┌────┴────┐
                                                     ▼         ▼
                                                COMPLETED   FAILED

CANCELLED is reachable from any state except COMPLETED, FAILED and CANCELLED.

Two transitions people expect to be able to skip, and cannot:

• You cannot start an approved change without scheduling it. APPROVED is authorization, not a date. The Schedule step is where freeze periods and collisions are checked, so skipping it would skip those checks.
• You cannot edit an approved change. Its content is what was authorized. Edit while it is DRAFT or PENDING_APPROVAL, or cancel and raise a new one.

---

Walkthrough — raising a change

1. Go to Changes → New Change (/org/changes/new or /msp/changes/new).
2. Fill in the title, description and reason. The reason is required to submit.
3. Set category, risk and priority. These decide which approval rule applies, so they are not cosmetic — a SECURITY / CRITICAL change may need more sign-offs than a routine one.
4. Add implementation, rollback and test plans. Your organization’s policy may require these for certain risk levels; submission is refused without them.
5. Save. The change is created as DRAFT.
6. Link affected assets if relevant. This matters: an approval rule can require MSP sign-off specifically when a change touches MSP-managed equipment.
7. Press Submit for Approval.

On submit, Solidlio evaluates your policies, resolves the approval rule, routes the change to a CAB, and notifies the approvers. If a policy is violated in a blocking way, submission is refused and the violations are listed; you can resubmit with an explicit override, which is recorded against your name.

To correct a mistake before it is approved, press Edit.

---

Walkthrough — approving a change

1. Go to Changes → Approvals (/org/changes/approvals). This lists only changes assigned to you.
2. Open a change and select the Approvals tab.
3. The Required sign-offs panel shows every board that must clear this change, how many approvals each has, and what is outstanding — for example “2/3 approved · 1 more CHAIR approval(s) required”.
4. Press Approve or Reject, optionally with a comment.

A rejection is decisive: one rejection moves the change to REJECTED regardless of how many approvals it already had.

When the last required sign-off lands, the change becomes APPROVED and the requester and assignee are notified.

---

Approval rules (change authority)

Where: Changes → Approval Rules (/org/changes/approval-rules) Tier: CAB or above

An approval rule answers: a change of this shape needs how many signatures, and whose?

Which rule applies

1. The highest-priority rule that matches.
2. If two match at the same priority, the one with more match criteria wins.
3. If still tied, the older rule wins.
4. If no rule matches, the CAB’s own minVotingMembers / requireUnanimous settings apply.

That last fallback means an organization that never writes a rule keeps working exactly as before.

Preview

The What would this change need? panel resolves the whole chain against a hypothetical change — pick a category, risk and type, tick “touches MSP-managed assets” if relevant, and press Resolve. It tells you the answer and which rule produced it, without creating anything.

Rules are snapshotted

When a change is submitted, the resolved bar is frozen onto it. Editing or deleting the rule afterwards does not change the bar that change had to clear, and the rule’s name is retained on the record. This is deliberate: you must be able to reconstruct why something was authorized months later.

---

Change Advisory Boards

Where: Changes → CAB (/org/changes/cab) Tier: CAB or above

A CAB is a named group of people with roles:

• CHAIR — receives approvals; can be required specifically by a rule
• VOTING — receives approvals
• ADVISORY — attends, does not receive an approval

Set isDefault on the board that should catch changes no routing rule claims, and isEmergencyCab on the board that handles emergency retro-approvals.

Routing rules

Each CAB can carry routing rules that claim changes:

First matching rule wins, in priority order; otherwise the default CAB.

ASSET_CRITICALITY appears in older data but is rejected on save. Assets have no criticality field, so such a rule could never match — use ASSET_MANAGEMENT_SCOPE instead.

---

MSP co-management

An MSP sees, and can act on, changes across every client organization it services — as well as its own. What a client exposes is controlled per change by its MSP visibility:

Only the owning organization can change this setting. An MSP cannot widen — or hide — its own oversight.

Inviting an MSP onto a specific change

An organization runs its own CAB. When a change turns out to touch something the MSP is responsible for, invite them onto that one change:

1. Open the change → Approvals tab → MSP involvement.
2. Choose the MSP, say why, and decide whether their approval is required (binding) or advisory.
3. Send. The MSP is notified and can read the change — even if it is HIDDEN, because an explicit invitation overrides the default.
4. The MSP accepts (their own CAB is convened and becomes a gate) or declines.

Either side can back out: the organization can withdraw, the MSP can decline. Undecided approvals are removed and the change is no longer gated by them; votes already cast stay on the audit record.

Automatic escalation

An approval rule with MSP sign-off set escalates matching changes automatically on submit. This is a requirement rather than an invitation: it lands accepted, its vote binds, and neither side can decline or withdraw it. Combine it with Affected assets to express “escalate to our MSP whenever a change touches equipment they run”.

An MSP may never invite itself onto a client change.

---

Policies, freeze periods and conflicts

Where: Changes → Policies (/org/changes/policies) Tier: CAB or above

Policies are evaluated twice: when a change is submitted, and again when it is scheduled, against the date actually being chosen. The second evaluation is what makes blackout windows real — a change submitted with no date would otherwise slip past the freeze check entirely.

Conflicts (collisions with other changes or shared assets) are checked at scheduling time. Blocking conflicts and blocking policy violations are presented separately in the Schedule dialog, and each must be acknowledged on its own. Overrides are recorded in the audit trail against the person who made them.

---

Emergency changes

For a change that must happen now, press Emergency and supply a justification. Solidlio:

1. Moves the change straight to IMPLEMENTING and stamps the start time.
2. Sets a retro-approval deadline (48 hours by default, configurable per policy).
3. Routes it to your emergency CAB for retrospective approval.
4. Creates a post-implementation review, due in 7 days.

Retro-approval does not rewind the change — the approvals mark retroApprovalComplete rather than moving it back to APPROVED. A background job flags emergency changes whose retro-approval deadline has passed.

Emergencies can only be invoked from DRAFT or PENDING_APPROVAL.

---

Maintenance windows

Where: Changes → Maintenance Windows (/org/changes/maintenance) Tier: CAB or above

Named periods for planned work, optionally linked to a change and to affected assets. Windows move SCHEDULED → ACTIVE → COMPLETED, and can be cancelled. Background jobs activate and complete them on schedule, and each window’s card carries Activate, Complete and Delete for doing it by hand.

To choose the affected assets, select the “N assets” chip on the window’s card. That opens a picker listing the CIs already attached — each with its own Remove — above a search box for adding more.

With suppress alerts enabled and a monitoring integration connected, the window can suppress monitoring alerts for its assets for its duration (ADVANCED tier); use Sync monitoring on the card to push it. The assets you attach ARE the hosts that get silenced, so the control is disabled until the window has at least one — a window with no assets suppresses nothing. If the monitoring service cannot be reached on the way out, Solidlio retains the external IDs for retry rather than silently leaving alerts suppressed.

---

Post-implementation reviews

Where: Changes → Reviews (/org/changes/pir) for the list; the PIR tab on a completed or failed change for the review itself. Tier: CAB or above

A PIR records what actually happened. One is created automatically for every emergency change and every failed change; you can create one manually for any change that has completed or failed — open the change, choose the PIR tab and select Open a review. Rows in the Reviews list link straight to that tab.

A PIR captures whether objectives were met, what went wrong, whether the rollback was needed, lessons learned and follow-up actions, plus an overall score out of 10. Save review records the answers; Mark complete closes it and freezes it as part of the change record, so save before you complete. On ADVANCED, an AI analysis can draft the summary from the change’s history for a human to edit. Overdue PIRs are surfaced by a background job.

Answering a review is an administrator action (organization administrator and above), the same floor as the rest of the change lifecycle.

---

Templates

Where: Changes → Templates (/org/changes/templates)

Templates pre-fill a change with a standard plan — patching, certificate rotation, firewall rule updates. Solidlio ships a curated ITIL library you can import from, and MSPs can curate which library templates their clients see and push their own templates to client organizations.

Applying a template (BASIC) is separate from authoring one (CAB), so technicians on a lower tier can still use the standards their organization defines.

---

The audit trail

Where: Change detail → Audit Log tab

Every consequential action is recorded: creation, edits, each status transition, each approval decision, the resolved authority, quorum satisfaction, MSP engagement lifecycle, CAB routing, emergency invocation, policy overrides.

Entries record who, when, the previous and new values, and a human-readable summary. Approval decisions additionally record the quorum state at the moment of the decision — how many approvals each board had, and what was outstanding.

Audit writes are durable: the API does not respond until the record is written. A change that exists always has the trail explaining how it got there.

---

Notifications

---

Plan tiers

Change management is gated by a ladder: disabled < VIEW_ONLY < BASIC < CAB < ADVANCED.

Managed clients with no plan of their own inherit their MSP’s tier. Platform administrators bypass tier gates.

---

Troubleshooting

---

Limits and known behaviour

• Editing is restricted to DRAFT and PENDING_APPROVAL. Approved content is what was authorized. Cancel and re-raise if it must change afterwards.
• A rejection is final for that submission. There is no partial rejection or “reject back to draft”; raise a new change.
• CAB meeting schedules are informational. meetingDayOfWeek, meetingTimeUtc and meetingDurationMin are recorded and displayed but do not drive automated scheduling.
• Approval rules are per organization. An MSP configures each client’s rules individually; there is no push-a-rule-to-all-clients operation. Templates do support push-to-org.
• An engagement with no reachable CAB is advisory. If an invited MSP has no CAB configured, the requirement is recorded as advisory rather than binding, so the client is never deadlocked behind a board that does not exist.
• Asset-derived rules need linked assets. A change with no assets linked can never match a rule that specifies asset scopes.
• Mobile. Change management is web-only today.