Interpretation
How do you interpret the customer's words?
The customer is preparing a large macOS and Windows deployment (thousands of devices) where surfacing failed policies to end users is a key part of their self-remediation strategy. They reviewed the in-design wireframe for #39015 (Higher end-user visibility for policy failures) and feel the menu-bar icon change alone is too "light" of a signal. Their concern is that menu-bar indicators can be hidden by the user, hidden behind the laptop notch on Apple Silicon Macs, or simply missed because users have learned to ignore passive visual cues. They want a stronger signal — an OS-level push notification — that fires when a policy enters a failed state, so the user is actually prompted to act rather than relying on them to notice a small icon change.
They also raised a broader product point: notifications should not be limited to policy failures. Patch policies (where an app will be force-quit if not updated by a deadline) and other targeted user-facing actions deserve the same notification surface. The customer explicitly cited Jamf as the reference point: when a Jamf policy fails, the user gets a system-level notification naming the policy, and that single signal accelerates triage and reduces support overhead.
The customer is aware that notification fatigue is the obvious objection, and they pre-empted it: their position is that fatigue is solved through admin configurability, not by omitting notifications. They want notifications to be opt-in per policy, with admin-level controls (MDM-enforceable on macOS) so that only the policies that genuinely warrant user attention generate alerts.
What's Fleet missing?
Fleet Desktop today communicates policy state passively: the user has to open Fleet Desktop or notice a menu-bar visual change. Fleet has no mechanism to push an OS-level notification to the end user when a policy transitions to failed, when a patch policy is approaching its deadline, or when any other admin-defined event occurs on the host. There is also no per-policy or environment-wide configuration surface for controlling which events trigger end-user notifications and which channel (Fleet Desktop badge only vs. OS-level push) is used.
What does the customer's ideal workflow look like?
- An IT admin defines a policy in Fleet (via UI or GitOps) and, as part of the policy definition, selects whether end-user notification is enabled and which channel to use: Fleet Desktop badge only, OS-level push notification, or both.
- The admin can also set environment-wide (or team-wide) defaults — for example, "all patch policies generate an OS-level push, all CIS policies generate Fleet Desktop badge only, everything else generates nothing."
- A host runs a policy and transitions from passing to failing.
- The end user receives an OS-level push notification on their device naming the policy and surfacing the remediation guidance the admin has configured for that policy. The notification is clickable and opens Fleet Desktop directly to the failed policy's remediation view.
- The same notification surface is reused for patch events ("Slack will be quit and updated in 24 hours unless you update now") and other admin-defined triggers, so there is one consistent end-user notification model across Fleet rather than separate ones per feature.
- Because notification volume is admin-controlled per policy and per environment, end users only see alerts for events that genuinely require action — preserving signal and avoiding the fatigue that makes users dismiss notifications by default.
- On macOS, admins can deliver an MDM configuration profile that force-enables Fleet's notification entitlement so end users can't disable the channel, ensuring critical alerts always reach the user.
panoramix: Slack thread: Do want to call out that the current behavior is very confusing to the end users.Interpretation
How do you interpret the customer's words?
The customer is preparing a large macOS and Windows deployment (thousands of devices) where surfacing failed policies to end users is a key part of their self-remediation strategy. They reviewed the in-design wireframe for #39015 (Higher end-user visibility for policy failures) and feel the menu-bar icon change alone is too "light" of a signal. Their concern is that menu-bar indicators can be hidden by the user, hidden behind the laptop notch on Apple Silicon Macs, or simply missed because users have learned to ignore passive visual cues. They want a stronger signal — an OS-level push notification — that fires when a policy enters a failed state, so the user is actually prompted to act rather than relying on them to notice a small icon change.
They also raised a broader product point: notifications should not be limited to policy failures. Patch policies (where an app will be force-quit if not updated by a deadline) and other targeted user-facing actions deserve the same notification surface. The customer explicitly cited Jamf as the reference point: when a Jamf policy fails, the user gets a system-level notification naming the policy, and that single signal accelerates triage and reduces support overhead.
The customer is aware that notification fatigue is the obvious objection, and they pre-empted it: their position is that fatigue is solved through admin configurability, not by omitting notifications. They want notifications to be opt-in per policy, with admin-level controls (MDM-enforceable on macOS) so that only the policies that genuinely warrant user attention generate alerts.
What's Fleet missing?
Fleet Desktop today communicates policy state passively: the user has to open Fleet Desktop or notice a menu-bar visual change. Fleet has no mechanism to push an OS-level notification to the end user when a policy transitions to failed, when a patch policy is approaching its deadline, or when any other admin-defined event occurs on the host. There is also no per-policy or environment-wide configuration surface for controlling which events trigger end-user notifications and which channel (Fleet Desktop badge only vs. OS-level push) is used.
What does the customer's ideal workflow look like?