Filter

I've been informed that the new AI Governance Dashboard can only be accessed by "owners" in Relay. We have users who would benefit from being able to access this dashboard but we don't want them to be owners in the system.

Need to be able to run reports on lockouts. I want to be able to find all of the lockouts for th past week in one place and investigate them. We are a one to one school where students take their devices home. Some weekends there are multiple lockouts and its hard to investighate them or even see them when I am not checking my email.

Issue Telemetry provides valuable endpoint information, but administrators still need to transform that information into an operational understanding of deployment health. WCPSS already has separate needs around identifying agents that stop reporting and around filtering/exporting Telemetry at organizational scale. A dedicated Agent Version Compliance dashboard would provide an immediate answer to a different operational question: How healthy is the current Lightspeed agent deployment across the organization? Requested Enhancement Add a dashboard that summarizes agent deployment and version compliance across managed endpoints. The dashboard should provide an immediate overview of: current agent version; previous version; outdated versions; unsupported versions; stale agents; devices that have never successfully reported; recent check-in status; version distribution by platform. Example Dashboard Windows Agent Compliance Current Version: 3.4.3 Current: 91.4% Previous Version: 6.8% Older Versions: 1.1% Stale / No Recent Check-In: 0.7% ChromeOS Current: 96.2% Previous: 2.7% Stale: 1.1% These values should be selectable so administrators can drill into the underlying devices. Organizational Filtering The dashboard should allow administrators to scope results by: school/location; operating system; organizational group; agent version; reporting state; last check-in range. This is especially important for determining whether a deployment problem is: district-wide; platform-specific; school-specific; isolated to a deployment group. Deployment Validation The dashboard should help administrators quickly identify conditions such as: rollout stalled at one school; significant population remains one version behind; devices stopped checking in after an update; one platform has a materially lower adoption rate; an expected deployment has not reached its intended population. Drill-Down Selecting any dashboard metric should open the underlying device population. Example: 327 Devices — Version 3.4.2 Selecting that result should provide the corresponding Telemetry records rather than requiring the administrator to reconstruct the query manually. Compliance Thresholds District administrators should be able to establish operational thresholds. Example: Compliant: Current version Warning: One version behind Noncompliant: More than one version behind Stale: No report in 7 days Lightspeed could then provide an overall deployment-health status. Requested Outcome Transform existing Telemetry information into an actionable agent-deployment health view. The desired model is: Telemetry tells us about individual devices. Agent Compliance tells us whether the deployment is healthy. Acceptance Criteria Current agent-version distribution is visible. Results can be separated by operating system. Stale/non-reporting agents are identifiable. Administrators can filter by location or organizational scope. Dashboard metrics support drill-down to affected devices. Version-compliance thresholds can be configured where practical. Results can be exported or used in scheduled reporting. Business Value This enhancement would: improve proactive agent management; make deployments easier to validate; identify rollout failures earlier; reduce reactive support; improve upgrade planning; provide enterprise-scale fleet visibility.

Issue Web Activity reporting does not always identify the specific custom configuration object responsible for an allow or block decision. Administrators may see a generic result such as: Access List Custom List Custom Category without being shown the exact Access List or custom object that caused the decision. This creates unnecessary ambiguity during troubleshooting and policy review. Current Limitation Web Activity already exposes useful decision information, including whether traffic was allowed or blocked by category or Access List. However, the report does not consistently display the specific Access List name associated with the decision. This means an administrator can know that an Access List affected the request without knowing which Access List was actually responsible. Operational Impact Generic attribution increases the time required to troubleshoot filtering behavior. When reviewing a blocked or allowed request, administrators may need to: search through multiple Access Lists; review policy assignments manually; compare several possible custom categories; reconstruct the decision path outside the activity record. This is especially inefficient in environments with many custom lists and policies. The activity record should provide enough information to explain the filtering decision directly. Requested Enhancement Add explicit object-level attribution to Web Activity reporting. Where a filtering decision is caused by a custom object, the report should identify the exact object name. Examples: Current Blocked by: Access List Preferred Blocked by: Access List — Student Gaming Block Current Allowed by: Custom List Preferred Allowed by: Access List — Approved Instructional Resources Current Blocked by: Custom Category Preferred Blocked by: Custom Category — District Restricted Services Reporting Fields Where applicable, Web Activity should expose: decision type; exact Access List name; exact Custom Category name; applicable policy; allow/block result; other relevant policy object responsible for the final decision. If multiple objects contributed to the result, the report should identify the final controlling object and, where practical, the relevant decision path. Preferred UI Design The exact object name should be visible directly in Web Activity without requiring administrators to navigate into multiple additional console areas. This could be implemented as: a dedicated Access List column; a dedicated Decision Source column; an expandable decision-details view; clickable object names linking directly to the relevant configuration. A dedicated Access List column would align well with the existing reporting model. Export Requirement The specific object name should also be included in exported Web Activity data. If the console identifies the Access List or Custom Category responsible for a request, that information should remain available when the report is exported for troubleshooting, auditing, or analysis. Requested Outcome Provide clear attribution of the exact custom object responsible for an allow or block decision. The desired behavior is: Decision type + exact object name rather than: Generic object type only Acceptance Criteria This request would be considered addressed when: Web Activity identifies the specific Access List responsible for an allow or block decision. Custom Category names are displayed where applicable. Generic labels such as “Custom List” are not used when the specific object is known. The object name is visible directly in Web Activity or an immediately accessible details view. The same attribution is preserved in exported Web Activity data. Administrators can quickly identify which configuration object produced the reported result. Business Value This enhancement would: reduce troubleshooting time; improve policy transparency; make Web Activity more useful as an administrative diagnostic tool; reduce manual policy correlation; improve auditing and reporting; allow administrators to understand filtering decisions directly from the activity record. The requested improvement is simple: If Lightspeed knows which custom list or category made the decision, Web Activity should show its name.

Issue Web Activity reporting for unmanaged devices does not always accurately reflect the policy context under which the request was filtered. When Smart Shield activity cannot be matched to a rostered user, Web Activity may report the district root/default policy rather than the policy associated with the Smart Shield group handling the traffic. This can create a misleading administrative record. Current Behavior Lightspeed has indicated that when a user can be matched to a rostered identity, Web Activity can display the policy associated with that user. When no user match can be made, the reported policy may fall back to the district root/default policy. For unmanaged devices using Smart Shield, this does not necessarily represent the actual policy context applied to that traffic. The Smart Shield is already assigned to a group, and that group has an associated policy relationship. Operational Impact Incorrect or misleading policy attribution creates unnecessary difficulty when troubleshooting unmanaged-device activity. Administrators may see a request associated with the district default policy and reasonably conclude that the device was filtered under that policy, even when the Smart Shield group represents a different intended policy scope. This complicates: policy troubleshooting; Smart Shield validation; unmanaged-device investigations; reporting consistency; verification of policy changes; support escalation; audit review. Web Activity should accurately represent the filtering context that produced the result. Requested Enhancement For unmanaged Smart Shield traffic, Web Activity should report the policy associated with the Smart Shield or Smart Shield group whenever that relationship is known. The reporting logic should use the most accurate available source of policy attribution. A preferred order would be: Matched user policy, where a valid user identity is available. Smart Shield group policy, where the traffic is associated with a configured Smart Shield group. District root/default policy only when no more specific policy context is available. Example Current Reporting Device: Unmanaged User: Unknown Smart Shield Group: Guest / BYOD Reported Policy: Baseline This can imply that Baseline was the meaningful filtering context simply because no user identity was matched. Preferred Reporting Device: Unmanaged User: Unknown Smart Shield Group: Guest / BYOD Applied / Reported Policy: Guest / BYOD Policy This provides administrators with the policy context actually associated with the Smart Shield configuration. Reporting Transparency Where the policy shown is determined by fallback logic rather than direct user assignment, the interface should make that clear. For example: Policy Source: Smart Shield Group or Policy Source: District Default This would help administrators understand why a particular policy is being displayed. Requested Outcome Ensure that Web Activity reports the most accurate available policy context for unmanaged devices. The desired behavior is: Use the policy associated with the Smart Shield context when no user-specific policy is available rather than: Default to the district root policy whenever the user cannot be identified. Acceptance Criteria This request would be considered addressed when: Web Activity identifies the policy associated with the Smart Shield group for unmanaged traffic where applicable. The district root/default policy is used only when no more specific policy context is available. Reporting clearly identifies the source of the policy attribution where practical. Administrators can distinguish user-based policy attribution from Smart Shield-based attribution. Exported Web Activity data preserves the same accurate policy information. The policy shown in reporting accurately reflects the configuration context used to filter the request. Business Value This enhancement would: improve Web Activity accuracy; reduce troubleshooting ambiguity; improve Smart Shield validation; provide more reliable policy reporting for unmanaged devices; reduce false assumptions during support investigations; improve consistency between configuration and reporting. The requested principle is straightforward: If Lightspeed knows which Smart Shield group handled the request, reporting should use that policy context instead of presenting a less-specific default policy.

If there are criteria that you use a lot when in the web activity log section, it would be helpful to be able to load preset search criteria that you utilize frequently.

When viewing the Videos report it would be nice to see a thumbnail to go with the video title.

Currently, the only way I can find to review what specific YouTube videos have been blocked is to check each user's Website History individually. The Videos report doesn't say whether a video is blocked or allowed (does it only display allowed videos?), and there's no way to filter it as such. I would suggest displaying the block or allow status in the Videos report, and allowing us to view blocked or allowed or both.

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.

Issue Search within Data Sync does not currently produce sufficiently predictable or useful results for administrative review. When administrators search for a user, group, school, organizational unit, or other synchronized object, the returned results may not prioritize the most relevant match or behave in a way that makes the intended object easy to locate. For an administrative system, search should allow a user to quickly locate a known synchronized object without requiring repeated variations of the search term or manual review of a large result set. Operational Impact Unpredictable search behavior creates unnecessary administrative overhead when reviewing synchronization data. This impacts workflows such as: locating a specific user; locating a specific group or organizational object; validating synchronized records; investigating roster or assignment issues; confirming whether an expected object exists in Data Sync; troubleshooting synchronization-related problems. When administrators already know the object they are looking for, search should reduce the amount of manual investigation required. Requested Enhancement Improve Data Sync search so that results are ranked according to relevance rather than simply returning loosely matching records. Search should prioritize, where applicable: exact matches; exact identifier matches; starts-with or prefix matches; close relevant matches; partial matches. For example, if an administrator searches for a known username, email address, group name, or school name, the exact or closest matching record should appear first. Search Behavior The search function should support predictable matching against the fields administrators commonly use to identify synchronized objects. Where applicable, searchable fields should include: name; email address; username; unique identifier; group name; school/location; organizational unit; other relevant synchronization identifiers. If only certain fields are searchable, the interface or documentation should clearly identify those limitations. Exact Search Support Where technically possible, Data Sync should support exact-value searches for known identifiers such as: email address; username; object ID; group name. An administrator searching for an exact known value should not need to manually locate that object among unrelated partial matches. Search Transparency If Data Sync intentionally uses a specific matching method, such as substring matching, that behavior should be documented. The product should clearly identify: which fields are searched; whether search is exact, prefix, or substring based; whether multiple fields are searched simultaneously; whether special characters affect search behavior; any supported search syntax or operators. Preferred Result Ordering A predictable ranking model would be: Exact match → Exact identifier match → Prefix match → Relevant partial match → Other substring matches This would make the most likely intended record immediately visible while still allowing broader discovery. Requested Outcome Provide a Data Sync search experience that allows administrators to reliably locate known synchronized objects with minimal effort. The objective is not necessarily advanced search functionality. The primary requirement is that basic administrative search be: predictable; relevant; understandable; efficient. Acceptance Criteria This request would be considered addressed when: Exact matches are prioritized over partial matches. Prefix matches are prioritized over unrelated substring matches. Common administrative identifiers can be searched reliably. Search results are consistently ordered by relevance. Searchable fields are documented or identified in the interface. Any known search limitations are clearly documented. An administrator searching for a known synchronized object can locate it without repeatedly modifying the search term. Business Value Improved Data Sync search would: reduce administrative troubleshooting time; make synchronization validation faster; reduce unnecessary manual review; improve administrator confidence in Data Sync; simplify investigation of user, group, and synchronization issues. The desired outcome is simple: When an administrator knows what they are looking for, Data Sync search should help them find it immediately.