Plan One or Multiple Deployments
What
A Deployment applies every included Fileset to every included target. Use one Deployment only when every target should receive every Fileset with the same exclusions, Installation Type, activation and deactivation, installation timing, license distribution, revision behavior, and destination-platform requirements.
There is no single correct number of Deployments. Choose an organization that makes the current behavior clear and that you can extend safely when applications, target groups, or delivery rules change later.
Decide before you group assignments
Split assignments into separate Deployments when any of these settings need to differ:
| Setting | Use separate Deployments when |
|---|---|
| Assignment type | Some content installs automatically, appears in Kiosk, or exists only for license assignment |
| Activation and deactivation | Payloads need different start or end dates |
| Installation timing | Payloads need different installation windows |
| Kiosk rules | Items need different self-service visibility or presentation |
| Deployment on request | Only some payloads or target groups should use self-pickup behavior |
| Payload requirements | Platform, Booster, dependency, or runtime requirements do not match |
Fewer Deployments are easier to maintain only when the assignments genuinely share the same rules. Combining unrelated assignments merely to reduce the Deployment count makes later changes harder to understand and riskier to scope.
Organize by payload or destination
As a primary pattern, organize Deployments around the payloads being delivered or around the destinations receiving them. Avoid making both dimensions vary inside one Deployment unless the assignments still share every relevant delivery rule. Delivery method and platform are common reasons to separate otherwise similar assignments.
Worked example
For a simple example, Firefox and Chrome can share one Deployment assigned to the IT and HR groups only when both groups should receive both Filesets and every Deployment option matches.
For a larger example, suppose the following applications must be assigned to all managed Windows and macOS devices:
| Payload | Delivery | Destination |
|---|---|---|
| Google Chrome - Windows | Automatic installation | All Windows Devices |
| Google Chrome - macOS | Automatic installation | All macOS Devices |
| Firefox - Windows | Kiosk | All Windows Devices |
| Firefox - macOS | Kiosk | All macOS Devices |
| Adobe Acrobat Reader - Windows | Automatic installation | All Windows Devices |
| Adobe Acrobat Reader - macOS | Automatic installation | All macOS Devices |
| TeamViewer Host - Windows | Automatic installation | All Windows Devices |
| TeamViewer Host - macOS | Automatic installation | All macOS Devices |
Recommended grouping
- Standard Apps Windows (Automatic): Chrome, Adobe Acrobat Reader, and TeamViewer Host assigned to All Windows Devices
- Standard Apps macOS (Automatic): Chrome, Adobe Acrobat Reader, and TeamViewer Host assigned to All macOS Devices
- Optional Apps Windows (Kiosk): Firefox assigned to All Windows Devices
- Optional Apps macOS (Kiosk): Firefox assigned to All macOS Devices
This creates four reusable building blocks because the platform and delivery behavior differ. If Microsoft Teams later uses the same targets, Installation Type, timing, exclusions, license distribution, and revision behavior, add its Windows and macOS Filesets to the corresponding Standard Apps Deployments. If any option differs, give Teams a separate Deployment instead.