Issue Scheduled reporting should not be limited to simply emailing a static report at predetermined intervals. For a large district, reporting requirements vary significantly by audience, dataset size, security requirements, and operational workflow. WCPSS already identified scheduled export as a potential alternative for Leadership Dashboard access, but direct dashboard access remains preferable because repeatedly exporting information is inefficient. The same problem becomes even more significant with large operational datasets such as Telemetry, where the current export model is already constrained by a 50,000-device limit. Lightspeed needs a more comprehensive report automation and delivery framework rather than a simple “email this report weekly” capability. Requested Enhancement Allow administrators to define reusable report jobs containing: Dataset Examples: Web Activity Telemetry Agent Health Agent Version Compliance Leadership Dashboard Smart Shield activity other applicable administrative reports Scope Examples: district-wide; specific school/location; organizational group; platform; policy; agent version; category; custom filter set. Schedule Examples: daily; weekly; monthly; specific day/time; administrator-defined recurrence. Output Examples: CSV PDF structured data dashboard snapshot secure downloadable report Large-Dataset Challenge Traditional scheduled reporting creates a particular problem for large organizations. A report may contain: tens of thousands of records; hundreds of thousands of records; datasets too large for email; datasets exceeding synchronous export limits; information inappropriate for ordinary email attachment delivery. Therefore, the reporting framework should support multiple delivery methods rather than assuming every scheduled report can be attached to an email. Alternative Delivery Methods Lightspeed should consider supporting several enterprise-scale delivery options. Secure Report Repository Generate the report asynchronously and make it available within Lightspeed. Example: Scheduled Reports Report Generated Records Status Weekly Telemetry Aug 14 182,416 Ready Stale Agents Aug 14 1,243 Ready Authorized administrators could then download the report. Email could simply notify the recipient: Your scheduled report is ready. This avoids email attachment-size limits and unnecessary exposure of sensitive data. Partitioned Report Generation For exceptionally large datasets, Lightspeed could automatically generate multiple files. Example: Telemetry_001.csv Telemetry_002.csv Telemetry_003.csv The administrator receives the complete dataset without the interactive console needing to generate one enormous synchronous export. Cloud or Secure File Delivery For customers requiring automated downstream processing, Lightspeed could support secure delivery to an approved destination such as: SFTP; secure object storage; other supported enterprise file-delivery endpoint. This would allow districts to automate ingestion without requiring someone to manually download every report. API-Based Scheduled Data Job Where the Lightspeed API is licensed and available, the schedule could generate a predefined dataset accessible programmatically. This could be particularly useful for: SIEM ingestion; asset reconciliation; Power BI or other reporting platforms; internal data warehouses. Email Delivery for Smaller Reports Email should remain an option for appropriately sized reports. However, it should be one delivery mechanism rather than the architecture of the scheduled-reporting feature. Saved Report Definitions Administrators should be able to save a report definition independently of its schedule. Example: Report Name: Windows Agent Compliance – School Group A Filters: OS = Windows Version ≠ Current Location Group = Group A The administrator could: Run Now Schedule Clone Modify Export This would eliminate repetitive filter recreation. Delta Reporting For operational reports, an additional valuable option would be: Only include records that changed since the previous run. Examples: agents newly stale since yesterday; devices newly below required version; new blocks in a monitored category; newly detected unmanaged devices. For large districts, delta reporting can be far more actionable than repeatedly receiving the complete dataset. Exception-Based Reporting Another useful mode would be to generate a report only when a condition is met. Examples: stale agents exceed 2%; more than 500 devices remain below current version; a school falls below 90% agent compliance; report contains at least one matching record. This avoids generating meaningless reports when there is nothing requiring attention. Recipient and Access Controls Scheduled reports should respect Least Privilege Access. Administrators should be able to specify approved recipients or roles without granting those recipients broader console access. Sensitive reports should preferably use secure in-console delivery rather than attaching student or device-level data directly to email. Report History Lightspeed should retain a configurable history of generated scheduled reports including: report name; requested by; generated date/time; reporting period; record count; completion status; delivery status; expiration date. This provides accountability and allows administrators to retrieve a recently generated report without rerunning it. Failure Handling Scheduled reporting should clearly identify failures. Examples: Completed Completed with Partial Data Failed No Matching Records If a scheduled report cannot retrieve all expected data, it should never silently produce an incomplete dataset. Administrators should be notified when: generation fails; the dataset is truncated; delivery fails; authorization changes prevent delivery. Requested Outcome Create an enterprise scheduled-reporting framework that supports both traditional reports and large operational datasets. The preferred model is: Define Dataset → Apply Scope → Save → Schedule → Generate Asynchronously → Deliver Through the Appropriate Channel rather than: Run report → attach CSV to email Acceptance Criteria This request would be considered substantially addressed when: Administrators can save reusable report definitions. Reports can be scheduled on recurring intervals. Filters and organizational scope are preserved. Reports can be generated asynchronously. Large reports are not constrained by normal email attachment limits. Secure in-console report delivery is supported. Alternative enterprise delivery methods can be supported where appropriate. Administrators can generate complete datasets through partitioning or another scalable method. Email remains available for appropriately sized reports. Delta reporting is supported where practical. Condition/exception-based reporting is supported where practical. Report generation and delivery status are visible. Incomplete or truncated reports are explicitly identified. Scheduled reports respect Least Privilege Access. Report history is retained for an administratively defined period. Business Value An enterprise reporting framework would: reduce repetitive administrative work; provide leadership and technical teams with timely information; make reporting practical at large-district scale; remove dependency on interactive export limits; support operational automation; reduce sensitive-data exposure through email; enable downstream analytics and reconciliation; make Lightspeed reporting useful as an ongoing operational service rather than a manual console task. For a district operating at WCPSS scale, scheduled reporting needs to mean more than “email me this CSV every Monday.” It should mean: Get the right information to the right audience, at the right time, through a delivery method capable of handling the data.
