MSP Library

The MSP Library is your own versioned catalogue of Microsoft 365 configurations. You author a standard once (Conditional Access policy, Intune compliance profile, Exchange anti-phish rule, Defender ASR set, etc.), publish a version, assign it to the tenants that should have it, and Manage365 pushes it, monitors for drift, and handles upgrades when you publish a new version.

It's the same idea as the built-in Standards & drift library, but owned by your MSP — you decide the content, the cadence, and the upgrade path.

Core concepts

Standard

A named configuration that belongs to one of the supported kind values (see list below). A standard on its own does nothing — it needs at least one published version before it can be assigned.

Version

An immutable snapshot of the standard's payload plus thebuildOptions used to render it. Drafts can be edited; published versions are frozen forever. Publishing bumps the version number (v1, v2, …) and is a one-way door.

Assignment

A link between a standard and a scope. Three scopes are supported:

• msp — applies to every tenant the MSP manages (new tenants inherit it automatically)
• tenant_group — applies to every tenant in a named tenant group
• tenant — applies to one specific tenant

Scopes stack: a tenant can receive the same standard via themsp assignment and a more specific tenant assignment with override buildOptions.

Execution mode

Per assignment, choose how aggressive Manage365 should be:

• report — read the current config, record it, do nothing
• alert — raise an alert on any drift from the published version
• remediate — silently push the published config back on drift
• report_alert — report + alert
• report_remediate — report + remediate

Auto-upgrade flag

When you publish v2 of a standard, assignments withautoUpgrade = true roll to v2 automatically on the next scheduler tick. Assignments withautoUpgrade = false stay on their current version until an operator approves a migration plan.

Pinned version

Set a specific version number on an assignment and it will never move — not even if the auto-upgrade flag is on. Pinning is the escape hatch for “this one tenant needs v3 for audit reasons, hold it there”.

buildOptions and per-assignment override

Each standard kind accepts a small JSON options object —buildOptions — that parameterises the payload. Typical example: a Conditional Access MFA-for-admins standard takes a list of excluded group IDs in buildOptions.excludedGroups. The version's default buildOptions is the baseline; an assignment can override any subset of keys for a specific scope.

Application record

Every push writes an application record with a pre-push backup of the resource's prior state. If the push corrupts something, you roll back from that record rather than re-creating config by hand.

Drift finding

A row on the Drift page — one per (tenant, standard, resource) — describing the difference between the currently applied version and what's live in the tenant. Each finding can be remediated (push the published version back) or accepted (record the drift as intentional, suppress further alerts).

Migration plan

Generated when a new version is published and the affected assignment has autoUpgrade = false. A migration plan shows the diff between the current and new versions, lists which tenants would be affected, and waits for an operator to approve or reject. Approved plans are executed in the next scheduler tick.

Per-assignment override editor

Each row in the Assignments tab has an Override button that opens a JSON editor. The object you save is shallow-merged on top of the standard's published buildOptions at push time — keys you set win, keys you omit fall through to the version default. Useful for tenant-specific tweaks (different excluded UPNs, different threshold values, different watchlist domains) without forking the whole standard.

Empty body or {} clears the override entirely. A field-count badge appears on the button when an override is active so you can spot which assignments have been customised at a glance.

When to fork instead: if you find yourself copying the same overrides across many tenants, that's a signal you should publish a new version of the standard with the new defaults, not maintain N parallel overrides.

Dry-run preview

Before applying an assignment to a tenant, click Preview changes (dry-run) in the push dialog. The dry-run reaches out to the tenant, fetches the current state of the resource (if any), and returns one of four verdicts:

• create — no matching resource at the tenant. The full target body shows what will be created.
• update — resource exists. A diff table shows every field that would change, with the current value and the new value side by side.
• no_change — already in sync. Pushing would be a no-op. Common after a successful push or on a tenant that hand-rolled the same config independently.
• cannot_preview — couldn't reach the tenant or the handler threw. The reason is in the response. The target body still shows what would be applied if the live read worked.

Dry-run is read-only — no DB writes, no Graph mutations, no application records, no audit entries beyond the standard read activity. Safe to call repeatedly.

Starter packs

Empty libraries are friction. Two one-click starter packs are bundled with the platform — both available from the empty-state page and from the filter bar once the library has content:

1. 21 built-in CA templates — every Conditional Access policy template the platform ships with. Imported into your library as published v1 standards under theidentity category.
2. Intune + Exchange + Defender starter pack — eleven curated standards covering surfaces beyond CA:
   • 4 Intune compliance baselines (Windows, macOS, iOS, Android Enterprise work profile)
   • 3 Exchange transport rules (external-email warning banner, executable attachment block, DMARC fail watchlist quarantine)
   • Anti-phishing standard policy with mailbox + spoof intelligence
   • Safe Attachments — Dynamic Delivery
   • Safe Links — Standard posture
   • Defender ASR — Audit Baseline (every Microsoft-recommended ASR rule in audit mode)

Both imports are idempotent via name collision per kind — already-imported standards are skipped, not overwritten. So MSPs who've customised a Manage365 starter keep their changes when re-running the import to pull in newly-added starters.

Review before pushing. Starters ship with safe defaults — ASR rules in audit mode, transport rules with idempotency markers, compliance policies that mark non-compliant but don't block sign-in. Still: review each one against the target tenant's circumstances before assigning, and always dry-run before the first push.

Supported kind values

Thirty kinds are supported today, grouped by Microsoft product area:

Identity (Entra)

• identity.conditional_access_policy
• identity.named_location
• identity.authorization_policy
• identity.authentication_methods_policy
• identity.authentication_strength_policy
• identity.cross_tenant_access_policy

Intune

• intune.device_compliance_policy
• intune.device_configuration_policy
• intune.app_protection_policy
• intune.enrollment_restriction
• intune.autopilot_profile

Exchange Online

• exchange.transport_rule
• exchange.anti_phish_policy
• exchange.anti_spam_policy
• exchange.anti_malware_policy
• exchange.safe_links_policy
• exchange.safe_attachments_policy
• exchange.dkim_config

SharePoint

• sharepoint.tenant_settings
• sharepoint.sharing_capability
• sharepoint.site_template

Teams

• teams.meeting_policy
• teams.messaging_policy
• teams.calling_policy
• teams.app_setup_policy

Defender

• defender.asr_rules
• defender.advanced_settings
• defender.custom_detection
• defender.quarantine_policy
• defender.threat_policy

Lifecycle

1. Create a draft standard — pick a kind, give it a name, set the default buildOptions.
2. Publish v1 — the version freezes. You can now assign it.
3. Assign to a scope (msp / tenant_group / tenant) with an execution mode and autoUpgrade flag.
4. Push — manually from the assignment card, or wait for the scheduler to pick it up.
5. Drift sweep — Manage365 re-reads the config on a schedule. Any drift surfaces as a finding and (depending on mode) raises an alert or re-pushes the published version.
6. Accept or remediate each drift finding as it comes up.
7. Bump v2 when you want to change the payload. Publish the new version.
8. Assignments with autoUpgrade = true roll to v2 automatically. Assignments with autoUpgrade = false get a migration plan generated per affected tenant.
9. Approve or reject each migration plan. Approved plans are applied on the next scheduler tick.

Starter library

You don't have to build your library from scratch. On the MSP Library page, click Import starter templates and Manage365 will create 21 published Conditional Access templates in your library in one hit:

• MFA for all users
• MFA for admins
• Block legacy authentication
• Require compliant device for admins
• Require hybrid-joined or compliant device
• Block sign-in from high-risk countries
• Require app-protection policy for mobile
• Require password change on high-risk users
• Block guest access to non-Teams workloads
• …and twelve more

Each imported template arrives as v1, unassigned. Review, tweak buildOptions if needed, then assign to the appropriate scope.

End-to-end example

A walk-through: push a Conditional Access policy that blocks legacy auth to every customer tenant.

1. Import the starter library

POST /msp-library/standards/import-builtin-ca

Creates 21 CA templates in draft + publishes v1 of each.

2. Create an MSP-wide assignment

POST /msp-library/assignments
{
  "standardId": "<block-legacy-auth-id>",
  "scope": "msp",
  "executionMode": "report_remediate",
  "autoUpgrade": true
}

3. Push to every tenant

POST /msp-library/standards/<id>/push-all

The API streams per-tenant results. Each push writes an application record with the pre-push state of the affected CA policy (empty if the policy was new).

4. Drift sweep

Every hour the scheduler re-reads CA policies in every tenant. A customer admin disables the policy on Tuesday afternoon — the next sweep finds it, raises a drift alert, and re-pushes the published version because the mode is report_remediate.

5. New version

You decide to add a named location to the policy. Edit the standard, publish v2. Every assignment has autoUpgrade = true, so the next scheduler tick rolls all tenants to v2 with a fresh application record each.

Endpoints

Standards

Assignments

Drift & migrations

Permissions

• STANDARDS_READ — view the library, assignments, drift, migrations. Granted to every MSP role down to L1.
• STANDARDS_CREATE — author and delete drafts, import starters. L3 and above.
• STANDARDS_APPLY — assign, push, act on drift, act on migrations. L3 and above.
• STANDARDS_PUBLISH — publish a draft version and turn it into a frozen, assignable artefact. Restricted tomsp_owner and msp_admin only — publishing is the change-control gate.

Common pitfalls

• Pushing before publishing — a draft can't be assigned. Publish v1 first.
• Duplicate scopes — if a tenant receives a standard via both msp and tenant assignments, the tenant assignment wins.
• Missing permissions — some kinds need non-default GDAP roles. Check GDAP setup if a push returns 403 — the drift finding will name the role that needs adding.
• Deleting a standard with assignments — rejected with a 409. Remove the assignments first, then delete.
• Assuming auto-upgrade applies to pinned assignments — a pinned version overrides auto-upgrade. Clear the pin to let upgrades flow.