# How to resolve compliance policy conflicts in Hexnode UEM?

 Conflicting compliance policies can occur when more than one compliance policy is associated with the same device, user, device group, user group or domain and the policies evaluate the same device posture differently. In Hexnode UEM, admins should review policy targets, policy timing, default compliance behavior, and the configured compliance criteria to understand why a device received a specific compliance result.

Executive Summary
-----------------

 Compliance policy conflicts can create confusion when a device appears compliant under one policy but non-compliant under another. This usually happens when policies overlap across device groups, users, domains, or ownership categories.

 Admins should use clear names, scoped targets, platform-specific policies, ownership-based policies, and staged rollout groups to reduce conflicts.

 Common causes of compliance policy conflicts
---------------------------------------------

 This table explains common causes of conflicting compliance policies in Hexnode UEM.

CauseWhat HappensRecommended FixOverlapping device groupsA device belongs to two groups with different compliance policies.Use more specific groups or remove duplicate targeting.User and device targeting overlapA policy is applied through both user and device association.Choose a consistent targeting model for compliance policies.Default policy overriddenA newly applied custom policy overrides default compliance behavior.Review default and custom policy behavior before rollout.Cloned policy reused incorrectlyA cloned policy may retain settings that do not match the new target group.Review all criteria before assigning cloned policies.Corporate and BYOD devices share one policyPersonal devices may receive strict corporate checks.Create separate policies for corporate-owned and personal devices.Workflow to resolve conflicting compliance policies
---------------------------------------------------

1. Log in to **Hexnode UEM**
2. Navigate to **Manage> Devices** and open the affected device to review its current compliance status
3. Identify the **compliance policy** currently associated with the device.
4. Review all user, device, group, and domain targets that may apply to the device.
5. Check whether a newer policy was applied after an older policy.
6. Open the **Policy Summary Tab** for each relevant compliance policy.
7. Compare Basic Settings, Advanced Settings, criteria, logic, and target scope.
8. Remove duplicate or unintended policy associations.
9. Create separate policies for different platforms, ownerships, or business units where needed.
10. **Save** changes and run a device scan remote action on the affected device by navigating to **Manage> Devices > Actions > Scan Device**
11. Confirm the device compliance result after the next check-in.

Conflicting compliance policy examples
--------------------------------------

 This table explains examples of conflicting compliance policies and how to resolve them.

ScenarioConflictResolutionWindows BitLocker conflictOne policy marks BitLocker disabled as non-compliant; another policy does not check BitLocker.Use a dedicated Windows corporate baseline and remove overlapping policy targets.BYOD iOS conflictBYOD iPhones receive a corporate supervision requirement.Use ownership criteria or separate BYOD and corporate iOS policies.macOS FileVault conflictA pilot FileVault compliance policy applies to all Macs by mistake.Limit pilot policy to a test device group.App compliance conflictA required app policy applies to a department that does not need the app.Map required app compliance policies to department-specific groups.Troubleshooting conflicting compliance policies
-----------------------------------------------

 This table explains common troubleshooting scenarios for conflicting compliance policies.

IssuePossible CauseRecommended ActionDevice result changed after policy editA newer policy or updated policy may have taken effect.Review modified date, policy version, and target count.Device belongs to multiple groupsSeveral group-based policies may apply.Review all device groups and user groups associated with the device.Default compliance behavior disappearedA custom policy may have overridden default compliance settings.Review custom policy criteria and re-add needed default checks.Compliance status does not updateDevice has not checked in or scan data is stale.Scan the device and confirm last check-in time.Best practices to avoid compliance policy conflicts
---------------------------------------------------

- **Use platform-specific policies:** Keep iOS, Android, Windows, macOS, ChromeOS, Linux, tvOS, and visionOS policies separate where possible.
- **Separate corporate and BYOD policies:** Avoid applying corporate-only checks to personal devices.
- **Use clear naming:** Include platform, ownership, and purpose in the policy name.
- **Limit broad domain targeting:** Use domain targets carefully because they may affect more devices than expected.
- **Review policy summary:** Check configured settings, version, modified date, and target count before rollout.
- **Pilot first:** Test new compliance policies on a small group before production deployment.