Policies

A policy is a bundle of RMM settings — what to monitor, what to alert on, what scripts to run on a schedule, what software to install, agent-update channel, and so on. Endpoints get their policy from a four-level hierarchy.

The hierarchy

Tenant defaults
   └─> Client policy (overrides tenant defaults for that client)
         └─> Site policy (overrides client policy for that site)
               └─> Endpoint override (overrides everything for one endpoint)

Each level only specifies what it wants to change. Settings not touched at a level are inherited from above. This means you can configure 95% of your fleet at the tenant level and only set the 5% of weird special cases lower down.

What's in a policy

A policy bundles settings across several categories:

Category	Example settings
Monitoring	What checks run (CPU, disk, services), thresholds, frequency.
Alerts	Which monitoring failures create tickets vs auto-resolve.
Scheduled scripts	Run script X every Monday at 3am, scoped to in-business-hours.
Software	Required software (auto-install if missing), forbidden software (alert if found).
Agent behaviour	Update channel (stable/early/pinned), check-in frequency, log retention.
Remote control	Whether Connect is enabled and how.
Self-service	What scripts end users can run, what approvals they need.
Integrations	E.g. whether Bitdefender data is pulled, which MSP360 instance to attach.

Setting the tenant defaults

Settings → RMM → Defaults.

These apply to every endpoint in every client unless overridden. The shipped defaults are reasonable but generic — review and tighten:

• The default check set assumes a typical office endpoint. For servers, you'll want stricter thresholds.
• Default agent channel is stable — leave it unless you have specific reason to change.
• Default scheduled scripts are minimal — typically just a weekly Windows-update check on Windows endpoints. Add your own.

Per-client policies

Client → Settings → RMM.

Override anything you want at the client level. Common patterns:

• Healthcare client: stricter disk-encryption checks, no remote-control without explicit consent prompt.
• High-VIP client: tighter monitoring thresholds (e.g. disk-space alert at 80% rather than 90%).
• Single-device-of-importance client: specific scheduled scripts (backup verification, etc.).

The client policy page shows you which settings are using the tenant default (greyed) and which you've overridden (highlighted).

Per-site policies

Client → Sites → site → RMM.

Same as client policy, scoped to one site within the client. Useful when the same client has wildly different environments — e.g. a head office with Windows servers and a remote site that's all Macs.

Most MSPs never use per-site policies. Don't reach for them unless client-level isn't granular enough.

Per-endpoint overrides

Agent → Settings → RMM.

Override anything for one specific endpoint. Use sparingly — endpoint-level overrides are fiddly to maintain and have a way of being forgotten.

Common legitimate uses:

• A specific endpoint runs an unusual workload (e.g. a database server inside an otherwise-office client). Bump the RAM thresholds.
• A test endpoint that always fails certain checks. Mute the check on this one device.
• A laptop where the user is going through a known performance issue. Temporary override while it's diagnosed.

If you find yourself making the same endpoint-level change across several endpoints, that's a sign you need a new site policy or even a new client policy.

Applying a policy change

Changes propagate to endpoints on their next agent heartbeat — typically within 30 seconds. To force a specific endpoint to pick up the new policy immediately:

Agent → Actions → Refresh policy.

Or, in bulk:

Client → Settings → RMM → Push to all endpoints now.

Viewing what a specific endpoint's effective policy is

Agent → Settings → Effective policy.

This shows the computed policy for that endpoint, with each setting annotated with where it came from in the hierarchy (Tenant / Client / Site / Endpoint).

When you can't figure out why a particular setting is what it is on a specific endpoint, this is the page that tells you.

Templates

Some policy settings (especially scheduled scripts) are easier to manage as templates — pre-defined bundles you apply by reference rather than copy-paste.

Settings → RMM → Templates lets you create:

• Check templates — "Server-grade monitoring", "Laptop monitoring".
• Script templates — "Weekly Windows update", "Monthly disk cleanup".
• Software templates — "Standard office build" (Office, Adobe Reader, Chrome).

Apply a template to a client or site policy and that policy inherits the template's contents. Update the template and everything that references it picks up the change on next heartbeat.

This is much cleaner than copy-pasting policy fragments across clients.

Common patterns

"Most clients get the standard; one client is special"

1. Set the tenant default policy with your standard settings.
2. For the one special client: client → Settings → RMM → override the few things they need.

"I have three tiers of service (gold/silver/bronze)"

1. Tenant default = bronze.
2. Create two templates: "Silver upgrades" and "Gold upgrades".
3. Tag clients with tier:silver or tier:gold and apply the matching template at client level.

"This one machine is always alerting on disk space because it's intentionally near-full"

1. Agent → Settings → RMM → endpoint override → bump the disk threshold.
2. Document why in the agent's notes field so future-you doesn't undo it.

Common issues

Setting an override doesn't seem to take effect. Check the endpoint's effective-policy view — the setting may be overridden at a lower level that you've forgotten about, or the agent may not have heartbeat-refreshed yet.

Schedule script "fires" but never runs. Common causes: the scheduled run is during off-hours, the agent was offline at the scheduled moment (it doesn't retry until next-scheduled by default), or the script has a syntax error that's silently exiting. Check the script log on the endpoint.

I deleted a template, now policies that referenced it are weird. Templates can be deleted only if nothing references them — if you forced a delete via the API, dependent policies revert to "the values that were in place at delete time" but lose their connection to the template name. Re-create the template and re-link if needed.

Next

• Monitoring & alerts — the actual checks that policies enable
• Scripts & automation — scripts you'll bundle into policies