Organisational units and policy inheritance
Organisational units are the main scope for devices, users, apps, and policies. Plan the hierarchy before enrolling a large fleet.
Design the hierarchy
Create units around a stable management need, such as:
- Device purpose: office, shared, kiosk, signage.
- Site or region.
- Security or compliance level.
- Pilot and production stages.
Avoid copying the reporting structure when it does not change policy. Keep the hierarchy shallow enough that administrators can predict inheritance.
Recommended starting structure
Enterprise
├── Pilot
├── Office
├── Shared devices
├── Kiosk
└── Signage
Add site-level children only when locations require different network, app, or device settings.
Create an organisational unit
- Open Organisational Units.
- Find the intended parent.
- Click New Organisational Unit.
- Enter a clear, durable name.
- Save.
Use Edit to rename a unit and Delete only after users, devices, and required policies have been moved elsewhere.
How inheritance works
Settings applied at a parent unit flow to child units. A child can override a setting locally. The console identifies whether a value is inherited or locally applied.
Before changing a parent:
- List the child units affected.
- Test the change in Pilot.
- Record local exceptions.
- Apply the parent change.
- Verify a representative device and user in each affected branch.
Move users or devices
- Move users from the Users page.
- Move a Kiosk or Business+ device from its device details page using Move To.
After a move, inherited policies and apps can change. Verify the destination before moving a batch.
What's next
- Manage users and invitations, invite people and assign roles or organisational units.
- Configure device policies, apply settings to a pilot organisational unit.
- Dashboard and notifications, monitor the result of administrative changes.