Skip to content

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.

Partner (lowest priority)
└── Organization
└── Site
└── Device Group
└── Device (highest priority — always wins)

A policy can bundle up to 8 feature types:

FeatureWhat it controls
Patch ManagementAuto-approval, schedule, reboot policy
Alert RulesConditions, severity, cooldown, notification templates
Maintenance WindowsRecurrence, duration, alert/patch/automation suppression
Compliance RulesDesired-state rules, enforcement level, remediation script
BackupSchedule and retention
SecuritySecurity policy settings
MonitoringCheck configuration
AutomationEvent triggers, cron schedules, bulk actions

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.

Compliance rules support three enforcement levels:

ModeBehaviour
monitorReport non-compliance only. No action taken.
warnLog a warning and send notifications.
enforceAuto-remediate using the linked remediation script. Falls back to warn if no script is set.
  1. Navigate to Configuration → Policies.

  2. Click New Policy.

  3. Enter a Name and optional Description.

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

  5. Click Save to open the policy detail editor.

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

FieldDescription
Auto-approveAutomatically approve patches matching the configured criteria
ScheduleFrequency (daily/weekly/monthly) and time of day for patch runs
Reboot policyHow to handle required reboots after patching

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
  • Severitycritical, 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.

FieldDescription
RecurrenceDay of week or month when the window applies
Start timeLocal time the window begins
DurationLength of the window in hours
Suppress AlertsSilence alert notifications during the window
Suppress PatchingSkip scheduled patch jobs during the window
Suppress AutomationsSkip automation triggers during the window
Suppress ScriptsSkip scheduled script execution during the window
FieldDescription
NameA label for this rule
Rule definitionThe desired-state condition to evaluate
Enforcement levelmonitor, warn, or enforce
Check intervalHow often to re-evaluate (minutes)
Remediation scriptScript to run when enforce mode detects non-compliance

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

FieldTypeDescription
Backup ModeenumWhat to back up: file (default), hyperv, mssql, or system_image
ScheduleJSONBFrequency (daily, weekly, monthly), time (HH:MM), timezone, day of week/month
RetentionJSONBkeepDaily, keepWeekly, keepMonthly snapshot counts
PathsJSONB arrayDirectories to include (file mode only)
TargetsJSONBMode-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).

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

  1. Open the policy detail editor → Assignments tab.

  2. Choose a Target type: Partner, Organization, Site, Device Group, or Device.

  3. Select the specific target from the dropdown.

  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.

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.
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.

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

The job is created with the schedule defined in the policy’s patch settings (e.g., weekly on Sunday at 2 AM).

All paths are relative to /api/v1.

MethodPathDescription
GET/configuration-policiesList policies
POST/configuration-policiesCreate policy
GET/configuration-policies/:idGet policy
PATCH/configuration-policies/:idUpdate metadata
DELETE/configuration-policies/:idDelete (cascades to features and assignments)
GET/configuration-policies/:id/featuresList feature links
POST/configuration-policies/:id/featuresAdd feature
PATCH/configuration-policies/:id/features/:linkIdUpdate feature settings
DELETE/configuration-policies/:id/features/:linkIdRemove feature
GET/configuration-policies/:id/assignmentsList assignments
POST/configuration-policies/:id/assignmentsAssign policy to a target
DELETE/configuration-policies/:id/assignments/:aidUnassign
GET/configuration-policies/effective/:deviceIdResolve effective config for a device
POST/configuration-policies/effective/:deviceId/diffPreview change diff
GET/configuration-policies/assignments/targetList assignments for a target
POST/configuration-policies/:id/patch-jobCreate patch deployment job
GET/configuration-policies/:id/patch-settingsGet patch settings for a policy
GET/configuration-policies/:id/resolve-patch-config/:deviceIdResolve patch config for a specific device

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

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.