Configuration Policies

Configuration Policies let you bundle device settings — patches, alerts, maintenance windows, compliance rules, and more — into reusable templates and apply them to any scope of your fleet. Policies evaluate automatically on a schedule and can auto-remediate drift without manual intervention.

Policies are hierarchical: settings cascade from the broadest scope down to the most specific, and more specific assignments always win.

Breeze Defaults  (lowest priority — read-only, always present)
  └── Partner
        └── Organization
              └── Site
                    └── Device Group
                          └── Device  (highest priority — always wins)

Policy ownership: organization vs. partner-wide

A policy is owned at one of two scopes:

• Organization — the policy belongs to a single customer organization and can only be assigned within that org’s hierarchy. This is the default.
• Partner-wide (all orgs) — the policy belongs to your partner account and can apply across every organization you manage. Use this for fleet-wide standards you want enforced everywhere without recreating the policy per customer.

You choose the ownership scope when creating the policy. Partner-wide policies can only be created and managed by partner-level users with full access to every organization under the partner (not users restricted to a subset of organizations); organization-scoped users see partner-wide policies in their effective configuration but cannot edit them.

Backup settings cannot be configured on a partner-wide policy — see Backup below.

Feature types

A policy can bundle multiple feature types:

Feature	What it controls
Patch Management	Auto-approval, schedule, reboot policy
Alert Rules	Conditions, severity, cooldown, notification templates
Maintenance Windows	Recurrence, duration, alert/patch/automation suppression
Compliance Rules	Desired-state rules, enforcement level, remediation script
Backup	Schedule and retention
Security	Security policy settings
Monitoring	Check configuration
Automation	Event triggers, cron schedules, bulk actions
Privileged Access	Windows UAC elevation prompt capture for privileged access management
Vulnerability Scanning	Turns on daily CVE correlation for the scope (off by default) – see vulnerability management

Each feature can be configured in one of two modes:

• Linked — points to an existing policy object by ID (e.g., an existing alert rule). Changes to the linked object propagate automatically. Not available for monitoring — use inline instead.
• Inline — settings are stored directly in the policy. Useful for simple configurations that don’t need to be shared. Required for monitoring, backup, and security feature types.

Enforcement modes

Compliance rules support three enforcement levels:

Mode	Behaviour
monitor	Report non-compliance only. No action taken.
warn	Log a warning and send notifications.
enforce	Auto-remediate using the linked remediation script. Falls back to warn if no script is set.

Creating a policy

1. Navigate to Configuration → Policies.

2. Click New Policy.

3. Enter a Name and optional Description.

4. If you’re a partner-level user with full access to every organization, an Apply to picker appears: choose All organizations (partner-wide) to apply the policy across every organization you manage, or A specific organization and pick the target org from the dropdown. Users scoped to a single organization (or with access to only some organizations) don’t see this picker — their policy is always scoped to their own organization. Note that Backup settings can’t be configured on a partner-wide policy.

5. Set Status to Active. Inactive and archived policies are not evaluated by the scheduler.

6. Click Save to open the policy detail editor.

Adding features to a policy

Open the policy detail editor and click the tab for the feature you want to configure.

Patch Management

Field	Description
Auto-approve	Automatically approve patches matching the configured criteria
Schedule	Frequency (daily/weekly/monthly) and time of day for patch runs
Reboot policy	How to handle required reboots after patching
Manage Windows Update exclusively through Breeze	Windows-only. Off by default. When on, the agent suppresses the device’s native Windows Update automatic-install channel (it sets the NoAutoUpdate registry value under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU) so that device only receives updates through Breeze’s schedule and approval rings — no surprise reboots or out-of-band patches. Turning it back off returns update control to native Windows Update.

Patch Management is available on partner-wide (all organizations) policies — an update ring can be linked directly, and the policy patches devices across every organization you manage. Behind the scenes, deployments are still tracked per organization: creating a deployment job from a partner-wide policy produces one job per organization with matching devices, so each customer’s patch history and compliance reporting stay separate even though the schedule and approval rules are defined once.

Alert Rules

Add one or more alert conditions. Each condition requires:

• Metric — what to measure (e.g., cpu_percent, disk_percent)
• Operator — comparison (gt, lt, eq)
• Value — the threshold
• Severity — critical, high, medium, low, or info
• Cooldown minutes — minimum time between repeated alerts for the same device
• Auto-resolve — automatically resolve the alert when the condition clears

Optionally link a title and message template to control notification formatting.

Maintenance Windows

Field	Description
Recurrence	Day of week or month when the window applies
Start time	Local time the window begins
Duration	Length of the window in hours
Suppress Alerts	Silence alert notifications during the window
Suppress Patching	Skip scheduled patch jobs during the window
Suppress Automations	Skip automation triggers during the window
Suppress Scripts	Skip scheduled script execution during the window

Compliance Rules

Field	Description
Name	A label for this rule
Rule definition	The desired-state condition to evaluate
Enforcement level	monitor, warn, or enforce
Check interval	How often to re-evaluate (minutes)
Remediation script	Script to run when enforce mode detects non-compliance

Backup

Caution

Backup is not available on partner-wide (all organizations) policies. Backup settings are always tied to a single organization, so a policy owned at the partner level has no organization to attach them to — attempting to add or save a Backup feature link on a partner-wide policy is rejected. Configure Backup on an organization-owned policy instead.

Backup feature links use inline settings stored in the config_policy_backup_settings table (one row per feature link).

Field	Type	Description
Backup Mode	enum	What to back up: file (default), hyperv, mssql, or system_image
Schedule	JSONB	Frequency (daily, weekly, monthly), time (HH:MM), timezone, day of week/month
Retention	JSONB	keepDaily, keepWeekly, keepMonthly snapshot counts
Paths	JSONB array	Directories to include (file mode only)
Targets	JSONB	Mode-specific targeting with optional exclude lists (Hyper-V and MSSQL modes)

Backup modes:

• File — backs up directories listed in the Paths field.
• Hyper-V — exports all discovered VMs by default. Set targets.excludeVms to skip specific VMs by name.
• MSSQL — backs up all discovered databases by default. Set targets.excludeDatabases to skip specific databases.
• System Image — full system image capture with no additional targeting needed.

Hyper-V and MSSQL modes use all-by-default targeting — newly created VMs or databases are automatically included on the next scheduled backup run without any policy changes.

When a backup feature is linked to a configuration policy, the schedule, retention, and mode settings in the policy override whatever is set on the standalone backup configuration. The policy system resolves which backup settings apply to a device using the same hierarchical precedence rules as other feature types (device-level wins over group, site, org, partner).

Tip

Use the effective configuration endpoint to verify which backup schedule a specific device will receive: GET /configuration-policies/effective/:deviceId

Security, Monitoring, Automation

Configure security policy settings for Security; check intervals and targets for Monitoring; and event triggers, cron schedules, and action chains for Automation.

Vulnerability Scanning

The Vulnerability feature is a single on/off toggle that controls whether the devices in the policy’s scope are scanned for CVEs. It is configured inline (the on/off state lives in the policy) and is off by default – a device with no vulnerability policy is never scanned, and its Vulnerabilities tab stays empty.

Open the policy’s Vulnerability tab, switch Enable vulnerability scanning on, save, and assign the policy. Because resolution is closest-wins, a device- or group-level setting of off overrides an organization-wide on. Once a scope is enabled, Breeze correlates its software and OS inventory against the CVE feeds once a day. If a policy exists but no device resolves to on, the daily job is simply a no-op – it never falls back to scanning everything. The findings themselves are reviewed and acted on in Vulnerability Management, not on this tab.

Assigning a policy

1. Open the policy detail editor → Assignments tab.

2. Choose a Level: Partner-Wide (All Orgs), Organization, Site, Device Group, or Device.

3. For Organization, Site, Device Group, or Device, select the specific target from the dropdown. For Partner-Wide (All Orgs) there is no target to pick — the assignment automatically covers every organization in your partner account.

4. Set a Priority number. When two policies at the same level both define the same feature, the lower priority number wins (priority 1 takes precedence over priority 2).

5. Click Assign.

Note

A device-level assignment always takes precedence over all group, site, organization, and partner assignments — regardless of priority number. A Partner-Wide (All Orgs) assignment is the broadest scope and is overridden by any more-specific assignment.

Per-device compliance status

Each device’s detail page surfaces how that device measures against every compliance rule from its assigned policies — separate from the Effective Configuration view. Open any device page and select the Compliance tab to see a row for every assigned policy’s compliance rules, including the rule name, current status (compliant, non-compliant, pending, or error), the last evaluation time, and any remediation attempts. This makes it easy to audit a single machine’s standing without leaving the device page.

The underlying endpoint is:

GET /policies/compliance/device/:deviceId

Breeze Defaults baseline

Every Breeze deployment ships with a built-in set of Breeze Defaults that sit at the bottom of the resolution hierarchy. These defaults are read-only — you cannot edit or delete them — but every policy you create at any level overrides them.

To inspect the current defaults, navigate to Configuration → Policies → Defaults (or go directly to /configuration-policies/defaults). The page lists every setting that Breeze ships with, shows its current value, and indicates whether it is Active (in effect for devices with no overriding policy) or Not enforced (the feature is present in defaults but not turned on by default).

Examples of shipped defaults:

Setting	Default state
Remote Access	Active (on)
PAM / UAC capture	Not enforced (off by default)
Vulnerability Scanning	Not enforced (off by default)

Each row on the Defaults page includes a Create override policy shortcut that opens the policy editor pre-configured for that feature, so you can add a partner- or org-level override without navigating away.

Defaults in the Effective Configuration tab

When a device has no policy assigned for a particular feature, the Effective Configuration tab on the device page attributes that value to Breeze Defaults and shows a Not enforced badge next to it, making it clear that the setting comes from the built-in layer rather than an explicit policy.

Viewing effective configuration

To see the merged settings a specific device will receive:

1. Navigate to the device’s detail page.
2. Open the Effective Configuration tab.
3. The page shows the resolved settings for each feature type and which policy in the inheritance chain provided each value — including Breeze Defaults for any feature not covered by an assigned policy.

GET /configuration-policies/effective/:deviceId

Use POST /configuration-policies/effective/:deviceId/diff to preview how a policy change would affect a device’s effective configuration before saving. The request body accepts:

{
  "add": [{ "configPolicyId": "uuid", "level": "site", "targetId": "uuid", "priority": 1 }],
  "remove": ["assignment-uuid"]
}

The response returns both current and proposed effective configurations for comparison.

Patch jobs

Policies with a Patch Management feature can trigger deployment jobs:

POST /configuration-policies/:id/patch-job

Request body:

{
  "deviceIds": ["uuid-1", "uuid-2"],
  "name": "Optional job name",
  "scheduledAt": "2026-03-01T02:00:00Z"
}

For each device, Breeze checks:

• Whether the device exists and is accessible — inaccessible devices are listed in skipped.inaccessibleDeviceIds
• Whether the device is inside an active maintenance window with patching suppression — suppressed devices are listed in skipped.maintenanceSuppressedDeviceIds
• Whether the device ID is valid — invalid IDs are listed in skipped.missingDeviceIds
• Whether the device belongs to the policy’s organization (org-owned policy) or to an organization under the policy’s partner (partner-wide policy) — devices outside that scope are rejected with a 403 rather than silently skipped, since patching someone else’s fleet is never allowed

The job is created with the schedule defined in the policy’s patch settings (e.g., weekly on Sunday at 2 AM). Targeting devices from a partner-wide policy creates one job per organization that has matching devices, so a single request can produce several jobs — the response lists every job created, each with its own orgId and device count.

API reference

All paths are relative to /api/v1.

Method	Path	Description
GET	/configuration-policies	List policies
POST	/configuration-policies	Create policy
GET	/configuration-policies/:id	Get policy
PATCH	/configuration-policies/:id	Update metadata
DELETE	/configuration-policies/:id	Delete (cascades to features and assignments)
GET	/configuration-policies/:id/features	List feature links
POST	/configuration-policies/:id/features	Add feature
PATCH	/configuration-policies/:id/features/:linkId	Update feature settings
DELETE	/configuration-policies/:id/features/:linkId	Remove feature
GET	/configuration-policies/:id/assignments	List assignments
POST	/configuration-policies/:id/assignments	Assign policy to a target
DELETE	/configuration-policies/:id/assignments/:aid	Unassign
GET	/configuration-policies/effective/:deviceId	Resolve effective config for a device
POST	/configuration-policies/effective/:deviceId/diff	Preview change diff
GET	/configuration-policies/assignments/target	List assignments for a target
POST	/configuration-policies/:id/patch-job	Create patch deployment job
GET	/configuration-policies/:id/patch-settings	Get patch settings for a policy
GET	/configuration-policies/:id/resolve-patch-config/:deviceId	Resolve patch config for a specific device

When creating a policy, set ownerScope to organization (the default) or partner. With ownerScope: "partner" the policy is owned partner-wide and any supplied orgId is ignored — the partner is always derived from the caller’s own token, never trusted from the request body. Creating a partner-wide policy requires partner scope (a 403 is returned otherwise). When assigning a partner-wide policy, use level: "partner"; the target is resolved from the caller’s own partner, so no targetId is required.

When calling the features endpoints, the featureType value must be one of: patch, alert_rule, maintenance, compliance, backup, security, monitoring, automation, pam, vulnerability.

Troubleshooting

Policy not applying to a device

Check that the policy is assigned at some level in the hierarchy. Open the device’s Effective Configuration tab — if the policy is not listed in the inheritance chain, it has not been assigned to any scope the device belongs to.

Compliance check not running

Ensure the policy status is Active and checkIntervalMinutes is set. The evaluation worker scans for due policies every 60 seconds; setting checkIntervalMinutes to 1 means a rule will be checked within 60 seconds of becoming due.

Patch job skipping devices

Check all three skipped lists in the response: missingDeviceIds, inaccessibleDeviceIds, and maintenanceSuppressedDeviceIds. A device in an active maintenance window with Suppress Patching enabled will be skipped automatically.

Enforcement not remediating

Enforcement mode must be set to enforce and a remediation script must be linked. Without a script, enforce falls back to warn behaviour.

Feature type conflict between policies at the same level

When two policies at the same hierarchy level both define the same feature type, the one with the lower Priority number wins (priority 1 beats priority 2). If priorities are equal, results are non-deterministic — assign distinct priorities to resolve the conflict.