When Policies are nested in a hierarchy, child Policies automatically inherit assets and settings from their parent. Understanding what is and isn't inherited is important when structuring your Policy hierarchy, as it directly affects what gets deployed to your devices.
How Inheritance Works
A parent Policy (also called a top-level Policy) deploys its assets to all devices in its child Policies as well as its own. This lets you define a common baseline of software and settings at the parent level while using child Policies to deploy additional assets specific to each group.
A few common examples of how this structure is used:
- MSPs managing multiple organizations: A top-level Policy deploys standard tooling to all clients, with separate child Policies per organization — and optionally, nested child Policies per department (for example, separate software sets for Marketing vs. Engineering).
- Education: A top-level Policy handles shared configurations, with child Policies separating student and teacher devices, or enforcing different restrictions by grade or classroom.
What Child Policies Inherit
The following asset types are inherited by child Policies from their parent:
- Software (Smart Software and PreBuilt Apps)
- MDM and DDM System Updates
- Device Settings
- Monitoring Items
- Maintenance Items
- OS Users
- Apple Apps Assets
- Addigy Identity
- MDM Enrollment Profiles
- Malwarebytes OneView
- Home Screen Layout
- Compliance
- Self Service Configurations
- Conditional Access
- Software Deployment Schedules
What Child Policies Do Not Inherit
The following are not inherited by child Policies:
- Autotask
- BrightGauge
- FreshDesk
- IT Glue
- Zendesk
- Apple Apps Tokens
- Automated Device Enrollment Settings and Tokens
- Splashtop Settings
Note: Apple Apps Tokens are not inherited, but apps themselves are. If a child Policy does not have its own token, it will still receive apps assigned in the parent Policy by default. This behavior can be configured — see Apple Apps Policy Inheritance for details.
Special Cases
LiveTerminal, LiveDesktop, and Splashtop
These tools only inherit disabled states from a parent Policy — they do not inherit enabled states. The practical effect is that a parent Policy can turn these features off for all child devices, but it cannot turn them on. Specifically:
- If Splashtop is disabled in the parent and enabled in the child, Splashtop will not install or enable on devices in the child Policy.
- If Splashtop is enabled in the parent and disabled in the child, Splashtop will not install or enable on devices in the child Policy.
Flex Policies
When a device is added to a Flex Policy, it follows the settings of its Location (root Policy) for tools like LiveDesktop. For example, if the Location has LiveDesktop enabled and the Flex Policy has LiveDesktop disabled, the device will keep LiveDesktop enabled.