Hard-delete tenants + MSPs

Hard-delete is the irreversible cleanup path. Soft-delete (the normal offboard flow) hides a record and detaches it from scanning; hard-delete wipes the row and everything linked to it. Both exist — this page covers when to use which, what actually disappears, and the guardrails that stop the worst kinds of accident.

Hard-delete vs soft-delete (offboard)

Default behaviour: when you remove a customer, soft-delete. Hard only when you're certain.

What hard-delete cascades

FK cascades pull the following linked records with the tenant:

• Cached Graph data: users, licences, devices, groups
• CA policy cache
• Compliance scan results (every historical scan)
• Standards application records + drift findings
• MSP Library assignments + application records for this tenant
• Alert history
• Notifications sent
• Change requests referencing this tenant
• Evidence bundles
• Playbook execution records
• NDB incidents
• Client-portal users assigned to this tenant
• Hudu / IT Glue push records

Platform-level records that reference the tenant by ID but aren't owned by it survive:

• Audit events (platform-level)
• Billing invoice lines
• MSP user accounts (they're not owned by the tenant)

Name-typed confirmation

The hard-delete endpoint refuses to operate without a matching confirmation string — the exact tenant name, typed by the operator. This catches the “I-meant-to-click-the-other-one” class of mistake before it runs:

DELETE /tenants/:id/hard
{
  "confirmationName": "Acme Health"
}

Wrong name returns 400 Bad Request withconfirmation name does not match tenant name. The UI disables the delete button until the typed name matches exactly — case-sensitive, whitespace-sensitive.

Partner-tenant protection

You can't hard-delete your own MSP partner tenant via the tenant-delete path. The endpoint returns 403:

403 Forbidden
{
  "message": "Cannot hard-delete the MSP's own partner tenant.
    Disable via /my-tenant first."
}

See Manage your partner tenant for the disable path. The partner tenant has real consequences (breaks MSP sign-in) if removed accidentally, so the path is deliberately on a different URL.

MSP hard-delete (platform admin only)

Manage365 also supports hard-delete of an entire MSP record — used when a partner leaves the platform entirely. Only platform admins (not MSP owners) have this permission, and the guardrails are stricter:

• You can't delete your own MSP — even as platform admin, deleting your own MSP would cascade your own user account, which is rejected
• Audit survives — the MSP hard-delete is logged at the platform level. The audit entry for the delete itself, plus any historical platform audit events, stay in the platform audit store.
• Invoices are preserved — any past billing records survive for accounting continuity. You keep the money; the customer record goes.
• Name-typed confirmation — same model as tenant hard-delete, typed MSP name must match exactly

The hard-delete cascades through every tenant under the MSP, every MSP user, every assignment, everything. Don't run it unless the departure is final.

Endpoints

End-to-end example: customer departure

1. Customer tells you 30/06/2026 is the last day. You stop new work, revoke their client-portal users.
2. On 30/06/2026 end of day: soft-delete the tenant via DELETE /tenants/:id. Billing prorates the final month.
3. Hold for 30 days as a safety window — if the customer changes their mind you can reactivate with all data intact.
4. After 30 days, if you're certain, run hard-delete. Type the tenant name into the confirmation field. Click delete.
5. Tenant row + cached Graph data + scan history + everything linked is gone. The platform audit log retains thetenant.hard_delete event permanently so you can prove the data destruction date if asked.

Common pitfalls

• Hard-delete first, regret later — always soft-delete, then hard-delete after a wait period. The data is gone gone; no backup restore on this path (backups are a different concern, out of scope for hard-delete UX).
• Name mismatch — tenant names with trailing spaces, non-breaking spaces, or unusual punctuation trip people up. Copy-paste from the confirmation prompt rather than typing by hand.
• Trying to hard-delete partner tenant — rejected with 403. Use /my-tenant → disable.
• Trying to hard-delete your own MSP — rejected by the platform-admin endpoint. You need another platform admin to do it (rare; usually only for MSP bankruptcy or merger cleanup).
• Expecting invoices to disappear — they don't. Invoice line items survive the delete for accounting purposes. The tenant row they referenced is gone; the invoice shows the tenant name as stored at invoice time.

FAQ

Does hard-delete revoke GDAP in Microsoft? No — hard-delete is a Manage365-side operation. The GDAP relationship with Microsoft remains until its natural expiry or until you revoke it in Partner Center. Revoke there manually if you want the Microsoft side cleared too.

What happens to scheduled jobs for the tenant? Cancelled on delete — the tenant ID no longer exists, so any queued job dequeues on next run.

Can I hard-delete an active tenant without soft-deleting first? Yes, technically — the endpoint doesn't require a prior soft-delete. But the UI path does, because skipping the soft-delete safety window is a bad default.

How long before the data is actually gone? Immediate at the database level. Backups contain the data per the backup retention policy (30 days by default). After 30 days, the data is not recoverable from any Manage365-owned store.