Webinar: Managing Macs with Intune: security, scale, & the modern enterprise fleet
Register to attend
Remote Management
Explanation

How MDM Device Group sync works

Petros Amoiridis

Most organizations that use Workbrew already manage their fleet through an MDM provider, and that MDM already has its own way of grouping devices. MDM Device Group sync bridges these two systems so you do not have to recreate and maintain the same groupings by hand in Workbrew.

Different providers, different concepts

MDM providers do not all use the same abstraction for grouping devices. Jamf has computer groups, Kandji uses tags, Fleet has labels, JumpCloud has system groups, SimpleMDM has assignment groups, and Microsoft Intune has security groups. Despite the different names, they all serve the same purpose: organizing devices into meaningful collections. Workbrew maps each of these to its own Device Groups, regardless of what the provider calls them.

This means the groups you see in Workbrew after a sync may not match the terminology you see in your MDM dashboard, but they represent the same sets of devices.

Pull-based sync, not real-time

Workbrew syncs device groups by polling the MDM's API on a schedule rather than receiving real-time updates via webhooks. This is a deliberate tradeoff. Webhook integrations require each MDM provider to support outbound notifications, and the specifics vary widely across providers. A pull-based approach works uniformly across all supported MDMs and avoids the complexity of managing webhook endpoints, delivery failures, and deduplication.

The practical consequence is that changes in your MDM are not reflected in Workbrew instantly. The automatic sync runs every six hours, and you can trigger a manual sync from the Workbrew Console with a 15-minute cooldown between syncs. The cooldown prevents excessive API calls to your MDM provider, which could lead to rate limiting.

How devices are matched

When Workbrew syncs a group, it needs to figure out which local Device records correspond to which devices in the MDM. It does this using the MDM device identifier, a unique ID that the MDM assigns to each device. During the initial connection or first sync, Workbrew stores this identifier against each Device.

If a device exists in the MDM group but Workbrew does not have a local Device with a matching identifier, that device is simply skipped. This can happen when a device is enrolled in the MDM but has not yet installed the Workbrew Agent.

What happens to orphaned groups

If a group is deleted or renamed in your MDM, Workbrew does not delete the corresponding Device Group. Instead, it detaches the group by removing its MDM link. The group stays in Workbrew with its existing name and becomes fully editable, just like a manually created group.

This design avoids a situation where deleting a group in your MDM silently removes the policies, Default Packages, or Brew Configurations you had attached to it in Workbrew. The group and its settings are preserved, giving you time to decide whether to keep, reassign, or delete them.

Synced groups and policies

Synced groups are read-only in terms of their name and device membership, since both are controlled by the MDM. But everything else about them works exactly like a manual group. You can attach policies, Default Packages, and Brew Configurations to a synced group, and those settings apply to whatever devices the MDM places in that group.

This separation is intentional. The MDM decides which devices belong together, and Workbrew decides what to do with that grouping. If a device is added to or removed from a group in the MDM, the policies follow automatically on the next sync without any action in Workbrew.

For details on how policies behave when a device belongs to multiple groups, see How policies apply to Devices in multiple groups.