Manage365 Docs

Change requests

Change requests are the structured bridge between a client saying “can you do X?” and your techs actually doing it. They live in the white-label client portal(or the MSP portal for internal-raised work) and flow through raise → triage → approve → execute → close.

Who can raise them

  • Client admin in the white-label portal.
  • MSP staff in the MSP portal on behalf of a client.
  • Inbound webhook — e.g. a form on your public site POSTs a change request (see inbound webhooks).

Type taxonomy

Six built-in types, each with its own SLA and default routing:

  • new_user — onboard. Client provides name, role, licence.
  • offboard — secure offboarding. Triggers the offboarding wizard when approved.
  • licence_change — assign / remove / swap SKU.
  • access_change — group membership, SharePoint, etc.
  • general — free-text change.
  • incident — something broke, client wants eyes on it. Typically promoted to a PSA ticket immediately.

Approval flow

  1. Client admin submits via the portal or a linked form.
  2. Optional MSP approval gate (configurable per client).
  3. Assigned tech picks it up from Change requests in the MSP portal.
  4. When type is new_user, offboard, or licence_change the tech can execute directly from the request — Manage365 opens the relevant wizard pre-filled with the request data.
  5. Close with notes. Notes go into the client's audit trail and fire the close email via the notification channels.

PSA sync

If a HaloPSA / ConnectWise integration is configured the request auto-opens a ticket with the right client, category, and priority. Updates bidirectional: adding a note in the PSA shows up in Manage365 and vice versa.

Evidence for compliance

Every change request is in the immutable audit log, chained by SHA-256 hash. For ISO 27001 / SOC 2 / APRA audits, the evidence bundle ZIP exports the full change-request history including approvals and close notes, keyed by tenant.

SLA tracking

Each request type has a default target time-to-acknowledge and time-to-resolve. Breaches surface in the dashboard and the service-desk wallboard. Per-client SLA overrides live inSettings → Change requests.