How Devices, Groups & Blueprints Work Together
The Core Workflow
The relationship between Devices, Groups, and Blueprints follows a simple three-step flow:
The flow is one-directional: a Blueprint is assigned to a Group, and every Device in that Group automatically receives the Blueprint's configuration. Change the Blueprint once, and every device in the group updates on its next check-in. No per-device configuration, no drift.
Real-World Example: Sales Team
Let's walk through a concrete scenario.
The Setup
Your company has 20 iPhones used by the sales team. You need:
- 8-digit passcode
- VPN always on
- Company CRM app installed
- Camera disabled
Step by Step
1. Create the Blueprint
In GuardMDM, create a blueprint called "Sales Security":
| Setting | Value |
|---|---|
| Passcode | 8 digits minimum |
| VPN | Always-on, company gateway |
| Required App | CRM (App Store ID: 123456) |
| Camera | Disabled |
2. Create the Group
Create a group called "Sales Team" and add all 20 iPhones to it.
3. Assign the Blueprint
Assign the "Sales Security" blueprint to the "Sales Team" group.
4. Done
On their next check-in, all 20 iPhones automatically:
- Enforce an 8-digit passcode
- Connect to the company VPN
- Install the CRM app
- Disable the camera
Multiple Blueprints, One Group
A group can have more than one blueprint assigned. Blueprints are merged together before being applied to devices.
Example: The "Sales Team" group could have both:
- "Sales Security" (passcode, VPN, camera)
- "Sales Productivity" (CRM app, email config, calendar sync)
Devices in the group receive the combined configuration from both blueprints.
One Blueprint, Multiple Groups
A single blueprint can be assigned to many groups at once.
Example: The "Company VPN" blueprint (VPN configuration) can be assigned to:
- "Sales Team"
- "Engineering"
- "Management"
- "Remote Workers"
Every device in all four groups gets the same VPN configuration. Update the blueprint once, and every group's devices update automatically.
Device in Multiple Groups
A device can belong to more than one group. When it does, it inherits the blueprints from all groups it belongs to.
Example: An iPhone belonging to both "Sales Team" and "Remote Workers" receives:
- From "Sales Team": Sales Security + Sales Productivity blueprints
- From "Remote Workers": Company VPN blueprint
The device gets the merged configuration from all three blueprints.
Blueprint Conflicts and Resolution
When multiple blueprints apply to the same device (through multiple groups or multiple blueprints on one group), settings can conflict.
How Conflicts Are Resolved
GuardMDM resolves conflicts using a priority system:
| Conflict Type | Resolution |
|---|---|
| Same setting, different values | The most restrictive value wins (e.g., 6-digit passcode overrides 4-digit) |
| Same app, different install type | Required overrides Optional |
| Same restriction, different state | Enabled (restricted) overrides Disabled |
| Same network config, different values | The last applied blueprint's value wins |
Example: Passcode Conflict
- Blueprint A: "Require 4-digit passcode"
- Blueprint B: "Require 8-digit passcode"
Result: The device enforces an 8-digit passcode (most restrictive wins).
Example: Camera Restriction
- Blueprint A: "Camera disabled"
- Blueprint B: "Camera allowed"
Result: The camera is disabled (restriction enabled wins).
Example: VPN Configuration
- Blueprint A: "VPN gateway: us-east"
- Blueprint B: "VPN gateway: eu-west"
Result: The VPN configuration from the blueprint assigned last to the group takes effect.
Best Practices to Avoid Conflicts
- ✅ Keep blueprints focused on a single concern (security, productivity, network)
- ✅ Use clear naming so you know what each blueprint does
- ✅ Test blueprint combinations on a small group before rolling out broadly
- ✅ Review the effective configuration for a device in the GuardMDM dashboard
- ❌ Don't create overlapping blueprints that set the same settings differently
- ❌ Don't assign blueprints to groups without checking for conflicts
Summary
| Relationship | Behavior |
|---|---|
| Blueprint → Group | Group receives the blueprint's settings |
| Group → Device | Device receives all blueprints assigned to the group |
| Multiple blueprints → One group | Settings are merged; conflicts resolved by priority |
| One blueprint → Multiple groups | All groups share the same configuration |
| Device in multiple groups | Device inherits blueprints from every group it belongs to |
Next: Learn about Enrollment