Skip to content

Exports

These views can be exported as CSV or XLSX: the device matrix, a single device's detail page, exceptions, billing reconciliation, device onboarding, anomaly alerts, the audit log and the per-client summary (the trends view reuses the client summary export). The exported rows are identical to what the same filters show on screen. Nothing is summarized or re-aggregated on the way out.

Format notes

  • CSV: UTF-8 with a leading byte-order mark and \r\n line endings, so it opens correctly in Excel without a manual encoding fix, plus a header row.
  • XLSX: a single sheet named after the view, header row bold and frozen, columns auto-sized, date/time columns kept as real typed date cells (not text), and severity cells tinted by level so a quick visual scan works even before you start filtering the sheet yourself.
  • Formula-safe cells: in a CSV, a cell whose text would start a spreadsheet formula (for example a device name beginning with =) is prefixed with a leading apostrophe so the spreadsheet shows it as text instead of evaluating it; in an XLSX it's stored as a text cell instead, unchanged. Nothing else about the values changes.
  • PDF: a formatted document, not a table dump. Only the per-client summary, described below, has a PDF. Every other exportable view stays CSV/XLSX only.
  • Filenames follow <view>-<yyyy-mm-dd>.<csv|xlsx|pdf>, sent as a normal file download.

What's exported

Whatever your current filters show is what gets exported -- exporting the device matrix filtered to one client and "only exceptions" gives you exactly those rows, nothing more and nothing less. The device matrix's five source columns export as the same tokens the on-screen symbols represent (OK, OK_STALE, MISSING, N/A, COUNT_ONLY), so a spreadsheet built from an export can never disagree with the UI it came from.

Size limit

An export is capped at 50,000 rows. If your filtered view is larger than that, narrow it (by client, severity, or source) before exporting -- this exists to keep a single export request from becoming a multi-minute job on either end. (This limit does not apply to the per-client summary below -- see that section for why.)

The per-client summary (QBR document)

Every client's summary page (the one-page management report linked from that client's row) exports as CSV, XLSX, or PDF, and the on-screen page has its own Print button for the identical document via your browser's print dialog. All three -- the screen, the download, and the PDF -- are built from the one shared summary computed for that client, so the underlying numbers (device counts, coverage percentages, exception counts, trend deltas, billing figures) can never drift apart between them: there is exactly one place they're calculated. The screen, the CSV and the PDF each lay the same numbers out in their own way.

Unlike the tabular exports above, this one is not "one row per table row" -- it's a small, fixed set of scalars (device count, coverage percentages, exception counts, trend numbers, billing figures, the top 5 open exceptions), which is why it has no 50,000-row cap: it never scales with how many devices or exceptions the client has.

The document has seven sections, always in this order:

  1. Header -- client name and the report date.
  2. Coverage -- one line per matrix column ("EDR 94% · 3 gaps").
  3. Narrative -- the plain-English trend summary: "You had N open exceptions last month. You fixed M. P are new." These numbers are the same 30-day trend the trends view shows for this client, worded as a sentence rather than left as a bare count -- a management report your client will actually forward, where the trend matters more than a single snapshot.
  4. Top exceptions -- the 5 highest-severity open exceptions (severity, then estimated value, then most recently seen), with a footnote for any that are suppressed.
  5. Billing -- the billing-pattern banner for this client (see billing reconciliation) plus any estimated monthly leak or overbilling.
  6. Onboarding -- the client's onboarding rollup (% fully onboarded, per-step miss counts), the same computation the device-onboarding export and screen use.
  7. Freshness -- one line per connected source category, so a summary built on stale data is never presented as more complete than it is.

The PDF is a rendering of that same document -- same seven sections, same numbers, same narrative sentences -- using the identical PDF engine scheduled reports use, laid out for printing (A4, margins, a header/table typeface matching the on-screen page as closely as a printed page and a browser page can match). It is not a second, separately-computed report.