03 App Dashboards

Dashboards

The app organizes its screens into sidebar groups. This page is a tour of each group. Every non-core screen can be hidden from Settings → Sidebar Visibility; the core screens (Overview, Devices, Data Sources, Settings) cannot be hidden.

Most dashboards read cached jamf-cli snapshots already on disk — opening a dashboard does not issue new API calls. Data is refreshed by collection (see Scheduling & Automation).

A health strip sits above whichever screen you are on. It reports data sources that have stopped collecting or fallen far behind their schedule, and any overdue or failing schedule, with a Collect now action that re-collects just what is behind — so you do not have to be on Security Posture to learn that security data stopped landing. See Automation Trust.

With no jamf-cli connection at all — a CSV-only workspace — most of these screens have nothing to show: Devices and Offline Outreach render from CSV columns (plus custom_eas / security_agents) and stay populated; everything else on this page needs jamf-cli data. See App Onboarding → Running without jamf-cli credentials for how a CSV-only or Jamf School-only setup gets through onboarding. Jamf School data doesn't feed these interactive dashboards either — it produces a separate generated workbook; see Jamf School.

Reports

• Overview — the fleet home screen: headline KPIs and score cards (including SIP, Firewall and Gatekeeper, chosen with Customize), an OS-distribution donut, top failing compliance rules, security-agent coverage, and recent activity. On a shared workspace it also says when another Mac is mid-run, so Refresh appearing to do nothing reads as "someone else is working" rather than a bug. On a macOS 27+ host with AI insights enabled, an AI Fleet Insight card turns the same daily digest into a plain-language summary — see AI Insights. A banner also surfaces when a scheduled run should have fired but didn't — see Automation Trust. Data source: daily summary digest (tier 3) — see Data Provenance.
• Fleet Overview — a multi-profile roll-up: one card per workspace with per-profile health signals, so MSPs and teams can scan every tenant at once. Data source: daily summary digest (tier 3) aggregated across profiles.
• Devices — the device inventory table with search, sort, and a Priority Action filter. The detail panel shows a per-device risk breakdown. Freshness chips show the age of each underlying data source (a red "never" chip flags a kind that's never been collected), and a "Collect now" banner appears when the cache is stale. FileVault off on a hardware-encrypted Mac reads "Off (hardware-encrypted)" and, under a policy that lowers it, adds no risk points. A value Jamf did not collect shows neutral, not red. Data source: per-device snapshots of computers and mobile-device inventory (tier 1).
• Device Lookup — find one device by serial, hostname, asset tag, or ID. Data source: per-device snapshot of computer detail from pro device <id> (tier 1).
• Trends — historical charts over archived snapshots, including SIP, firewall and Gatekeeper lines and, on macOS 27, an AI Trend Insight card that summarises how the offered metrics moved over the selected range. See Historical Trends. Data source: daily summary digest (tier 3) over time; see Data Provenance for metric definitions.
• Health Audit — instance health findings plus computer-group hygiene (empty and unused smart/static groups). Also hosts the Config Doctor's checks — config drift, Alerts rule validation, and Data accuracy (EA parse health, device-count reconciliation, EA coverage drift) — see Diagnostics & Troubleshooting. On macOS 27 an AI Audit Insight card suggests which findings to work first and what changed since the previous audit. Data source: pro audit (instance-config checks, fetched by the Run Audit button) and group lists (tier 1).
• Generated — the library of reports already produced, with Generate… (a sheet: a template or your own sheets, the formats XLSX, HTML, PDF and CSV, whether to collect fresh data first, and whether to run a Health Audit first), Export PDF, an inventory CSV export, and a Period report button that builds a start/end/change workbook for a rolling or calendar window — see Period Reports. Data source: generated report catalog (no single tier; see Data Provenance for report composition).

Posture

• Security Posture — a weighted Security Score ring, per-control KPIs (FileVault, SIP, firewall, Gatekeeper), prioritized action items, and an OS-version donut, all following the workspace's security policy (Config → Scoring): a control set to warning is not a P0 or P1 gap, an ignored one is left out, hardware-encrypted Macs with FileVault off are counted apart, and Macs that did not report a control are left out of its counts with a "not reported: N" note. On macOS 27 an AI Posture Insight card says which control to work first. Freshness chips show the age of the underlying data source. Data source: pro report security (tier 2) aggregates, device inventory and, for the hardware rule, the computers snapshot (tier 1).
• Compliance Posture — a compliance-band distribution donut (Pass / Low / Med-Low / Medium / High / No Data), control-coverage gaps, and a per-OS breakdown. When compliance.baselines configures more than one mSCP/STIG baseline (for example, one per OS or one per framework), each baseline gets its own donut; a device whose failure count exceeds that baseline's configured rule count is treated as No Data rather than a real High band. Historical Trends gains a matching baseline picker on its compliance-band chart once more than one baseline is configured. Control-coverage gaps follow the same policy; the legend under the bars explains warnings and not-counted controls. On macOS 27 the AI Posture Insight card also names the macOS version that accounts for most of the gap. Data source: per-device EA results for mSCP/STIG baselines (tier 1) and device inventory (tier 1).
• Compliance Benchmarks — per-benchmark compliance rates and device counts from the Jamf Platform API. Experimental; needs a jamf-cli profile whose auth method is platform, and Platform API turned on under Settings → Experimental Features. Shows a locked state until both hold. Data source: Jamf Platform API compliance-devices (tier 1) and device inventory (tier 1).
• Offline Outreach — stale devices bucketed into outreach tiers (31–90 / 91–180 / 180+ days) by stale age (the oldest date thresholds.stale_basis lists, by default the check-in) with a one-click clipboard mail-merge of the affected users. Data source: per-device last-check-in dates from device-compliance (tier 1) and device inventory (tier 1).

Operations

• Patch Compliance — per-title patch compliance with a failures drawer; a "Days Behind" column and a Patch Velocity card chart how quickly titles reach adoption once released — see Patch Velocity. Freshness chips show the age of the underlying data. Exports to CSV and PNG. Data source: pro report patch-status per-title (tier 2); per-device failures from --scan-failures (tier 1); title release dates from pro patch-software-title-configurations definitions (tier 2).
• OS Updates — managed software-update plan state, failed plans, and devices in an error state. Freshness chips show the age of the underlying data sources. Data source: pro report update-status plan summaries (tier 2); per-device failures from --scan-failures (tier 1).
• DDM Blueprints — Declarative Device Management status. On any Jamf Pro profile: DDM enabled N of M Macs, how many have reported, declarations by identifier with the Macs where each is inactive or invalid, and pending or failed DDM software updates — all from the weekly per-device scan. On a Platform API profile the blueprint deployment sections appear as well. Per-Mac detail is in Devices; failed and stuck MDM commands are in Health Audit → Command health. Data source: per-device pro declarative-device-management status-items (pro ddm-status before jamf-cli 1.29) (tier 1); Jamf Platform API blueprint definitions where available (tier 2).
• Policies & Profiles — a two-tab screen: policy configuration findings, and configuration-profile deployment status. Data source: pro report policy-status (tier 2) and pro report profile-status (tier 2).
• Extension Attributes — a neutral per-EA browser: how many devices report each EA (not a coverage percentage — EAs are custom and often legitimately sparse, so the screen never grades them against 100%) and top-value distributions. A drift callout flags EAs whose device count dropped sharply since the previous collect, comparing an EA against its own prior value rather than an absolute target. Data source: per-device EA results (tier 1) and device inventory (tier 1).

Fleet

• Mobile Fleet — iOS/iPadOS device counts, compliance signals, OS-version distribution, and a device/profile inventory. Data source: mobile-devices-list (one fetch with the General, Hardware, Security and User and Location sections, tier 1) and profiles (tier 2).
• Jamf Protect — Protect alerts, agent health, and insights. Shows an explicit "Protect not detected" state for tenants that do not run Jamf Protect. Data source: Jamf Protect GraphQL API (separate OAuth2 credentials, tier 2).
• Groups & Searches — computer and mobile-device group inventory (smart vs. static), plus advanced mobile-device searches. Data source: Classic API computer/mobile-device group lists (tier 1, same as the group lists in Health Audit above) and advanced mobile-device searches.

Automation

• Schedules — when the managed automation policy is on, this tab is the Automation screen: a single policy toggle that determines what the bundled background item runs for unattended collection and reporting, an Automation Health section (overdue/failing schedules), a Notifications section (Teams/Slack webhook configuration), and report-group management for consolidated multi-profile reports. When managed automation is off, it's the manual schedule editor instead. See Scheduling & Automation and Automation Trust. Data source: no tier (configuration and schedule management).
• Run History — streamed output from past collect and generate runs, including an "Explain this run" AI action on failed runs. A collect you start in the app (the first collect, Refresh, the Overview prompt, Collect now) is listed as "Manual collect"; the last 20 are kept. One the background item turned away because it was running records nothing — see AI Insights. Data source: no tier (local log files, not API data).

Configuration

• Config — the config.yaml editor, with a read-only From config.yaml tab for what no other tab edits. See Configuration & Templates. Data source: no tier (configuration only).
• Customize — the chart options generated workbooks use: whether to save chart images, and one OS chart per major macOS version, plus a switch to write the HTML report with every workbook. The Overview's Generate makes the Full Instance report; Generate… on Generated Reports, and jamf-reports generate --template, make the others. Overview score cards and sections are chosen on the Overview itself. Data source: no tier (user preferences).
• Data Sources — the inputs surface: cached jamf-cli data, the CSV inbox, and snapshot status. Data source: no tier (local workspace cache status).
• Backups — snapshot and compare Jamf Pro configuration backups. Diff Selected compares two backups: the Summary view collapses objects taking the same change into one line, and objects that changed the same field to different values into one card with a line each, instead of printing every changed object in full. Raw is the whole jamf-cli payload, one click away, and Copy takes the diff to the clipboard. Summary and Copy redact credential-shaped values (password hashes, recovery keys, pre-shared keys); Raw is deliberately unredacted, for scripting against. Data source: jamf-cli pro backup exports (tier 2).

System

• Settings — app preferences: the jamf-cli install/update check, connections, Workspace location (point every profile at a shared team folder — see Security & Operational Considerations), diagnostics, and Sidebar Visibility. Data source: no tier (app configuration).