As organizations expand their device fleets, the demand for flexible, modular configuration becomes increasingly critical. Policy Composition addresses this need by enabling the application of multiple policies to a single device. This allows administrators to layer specific configurations, app deployments, and assets without interfering with existing overarching settings.
Historically, Applivery’s policy model relied on a single, monolithic policy per device or group, which bundled all configurations, application deployments, and asset distributions together. While effective for simpler environments, this approach often limited agility in dynamic scenarios—such as targeted compliance updates, role-based application assignments, or phased rollouts—frequently necessitating full policy recreations or overwrites.
With Policy Composition, Applivery introduces a composable architecture that treats policies as reusable building blocks. Administrators can now construct device configurations by stacking multiple policies, setting priorities as needed, and dynamically assigning or revoking them. This granular control not only streamlines administrative operations but also reduces overhead and enhances security, compliance, and scalability across enterprise environments.
Key terminology #
Understanding the key terms below is essential for effectively managing device configurations using Policy Composition in Applivery:
- Policy: A configurable set of rules that define device behavior, including restrictions, app deployments, asset provisioning (e.g., certificates, Wi-Fi profiles), and compliance checks.
- Policy Composition: The method for applying multiple policies to a single device, with optional priority settings to resolve conflicts.
- Composition Set: The complete collection of policies assigned to a device, representing its effective configuration at any given time.
The Single-Policy Model #
In traditional Applivery deployments, each device or device group was assigned a single policy encompassing all configurations, including:
- Device configurations: Settings and restrictions, such as passcode requirements, camera access, and network restrictions.
- Applications: Managed apps deployed to devices, including in-house apps and public App Store applications.
-
Assets: Resources such as books, certificates, wallpapers, or other device assets.
While simple to manage in small environments, this model presented limitations in dynamic or complex scenarios. For instance, applying a temporary policy—like a time-sensitive compliance update—often required creating a new policy from scratch or modifying the existing one, which could unintentionally overwrite unrelated settings.
Introducing Policy Composition #
Policy Composition provides a modular approach to device management by allowing multiple policies to be applied to a single device or group. Each policy can focus on a specific aspect of the device—security, app deployment, branding, or other configurations—enabling administrators to manage and update settings without impacting unrelated configurations.
Key components #
Policy Composition is built on three fundamental concepts that give administrators flexibility and control over device configurations:
- Policy layers: Each policy acts as an independent layer. For example, a base policy may enforce general security settings (like encryption and passcode complexity), a departmental policy could deploy role-specific applications, and a temporary policy might enforce event-specific restrictions, such as enabling eSIM configuration.
- Priority and conflict resolution: When multiple policies are applied, Applivery’s Policy Composition Preview allows administrators to see the resulting configuration before deployment. Conflicts between settings are resolved according to the assigned priority of each policy.
- Dynamic assignment: Policies can be assigned or revoked in real time via Automation Rules, allowing updates without interrupting existing device configurations.
Architecture flow #
The Policy Composition workflow follows these steps:
- Policy creation: Administrators define individual policies in the Applivery dashboard, specifying configurations, apps, or assets.
- Policy assignment: Policies are assigned to devices or groups, optionally with priority levels to control how conflicts are resolved.
- Composition processing: The Applivery MDM server aggregates the assigned policies into a Composition Set, ensuring priorities are respected.
- Device sync: The composed configuration is pushed to devices using platform-specific protocols (Apple MDM, Android Enterprise, Windows MDM).
- Monitoring and updates: Any changes to policies are propagated automatically, with audit logs tracking assignments and conflicts.
Implementation guide #
Availability #
The Policy Composition feature is available across all areas where a single policy could previously be assigned. This includes Manual Enrollment Links, which allow creating links with multiple policies for initial device setup; Direct Device Assignment, where policies can be applied directly to individual devices; Smart Enrollments, which enable applying composed policies during automated enrollment workflows; and Automation Rules, allowing multiple policies to be applied based on Device Audience.
Assigning policies #
When assigning policies in any of these scenarios, an enhanced modal window opens, similar to the previous single-policy interface. Administrators can now add multiple policies to a device or group and control the order in which they are applied. Policies can be reordered either by using the interface arrows or by assigning numerical priority values, where lower numbers indicate higher priority at the top of the Composition Set.
The interface includes several elements to facilitate management. The policy list (1) displays all assigned policies, while the Priority (2) field lets administrators set the order of application. Interpolations (3) shows all dynamic variables used across policies, and the Preview (4) option allows reviewing the raw composed configuration before deployment. Finally, the Add policy (5) button lets administrators include additional policies in the set.
Platform-specific conflict resolution #
The behavior of the Composition Set varies depending on the device platform.
On Apple devices (iOS, iPadOS, macOS), policies are executed sequentially according to priority, with lower numbers taking precedence. For example, if three policies toggle the same setting, the device adopts the final state from the last policy in the sequence.
On Android devices, the priority order is maintained similarly, but in case of conflicting settings, the most restrictive configuration takes effect.
On Windows devices, policies also execute sequentially, respecting the assigned priority order.
Best practicies #
When using Policy Composition, assign clear priority values to avoid conflicts and confusion.
- It is recommended to test compositions in a pilot group before deploying them broadly.
- Regularly review audit logs to monitor policy application and resolve any conflicts.
- For better organization, use priority numbers below 100 for Automation Rules and above 100 for other policy assignments, ensuring Automation Rules consistently take higher precedence.