Filter

We would like to be able to review the results of the Sync Log. For instance, we want to be able to see specifically what information was not able to sync. Example of CSV Import of Import Admin Roles Sync below. We would want to know which Admin roles were not able to import, and what emails were not found, so we can make corrections. Admin roles imported: 161. Admin roles not imported: 6. Emails not found: 4.

Issue Lightspeed Filter allows administrators to create exceptions and configuration objects that may remain in place indefinitely unless someone manually reviews and removes them. This is particularly important for objects such as: Access List entries; SSL bypass entries; custom categories; temporary allow/block exceptions; vendor-specific exceptions. An exception may be appropriate when created but no longer necessary months or years later. Without lifecycle controls, temporary changes can effectively become permanent simply because their original purpose is forgotten. WCPSS already has a related governance concern with SSL List entries, where external tracking is necessary to document why entries exist and whether they remain needed. Requested Enhancement Allow administrators to optionally assign lifecycle metadata to applicable configuration objects. Suggested fields include: Review Date Expiration Date Business/Technical Owner Purpose / Justification Ticket or Change Reference Notes These fields should be optional so permanent entries are not forced into an expiration model. Review Date A review date should indicate that an entry must be evaluated but should not automatically remove it. Example: Domain: vendor-example.com Purpose: Temporary instructional pilot Review Date: October 30, 2026 When the date approaches, Lightspeed could identify the entry as: Review Due The administrator could then: extend the review date; confirm the entry remains valid; modify it; remove it. Expiration Date Where appropriate, administrators should also be able to specify an actual expiration date. Possible administrative behavior could include: automatically disable the entry; automatically remove it; require confirmation before removal; notify administrators and place it into an Expiring status. Districts should be able to select the preferred behavior. Notifications Lightspeed should support configurable notifications such as: 30 days before review; 14 days before expiration; 7 days before expiration; expiration reached. Notifications could appear in the console, administrative email, or scheduled governance report. Filtering and Reporting Administrators should be able to identify: entries approaching expiration; overdue reviews; expired entries; entries without an owner; entries without justification; long-standing exceptions. Requested Outcome Give administrative exceptions a manageable lifecycle rather than assuming every configuration entry should remain indefinitely. The desired model is: Create → Document → Review → Renew or Retire Acceptance Criteria Applicable administrative objects support optional review dates. Applicable objects support optional expiration dates. Administrators can record justification and ownership. Entries approaching review or expiration can be identified. Administrators can receive notifications. Review does not automatically remove an entry unless configured to do so. Expired or overdue entries can be filtered and reported. Business Value This would: reduce obsolete exceptions; improve security governance; simplify periodic audits; preserve institutional knowledge; reduce unnecessary access; improve accountability; reduce reliance on external tracking systems. The principle is simple: Exceptions should have a lifecycle, not just a creation date.

Issue Lightspeed Filter console search currently appears to rely heavily on substring matching. This means a search term may return records containing the entered character sequence anywhere within the value, even when a more relevant record begins with or exactly matches the search term. For administrative workflows, this makes search results unnecessarily difficult to interpret and can bury the intended result among less relevant matches. Current Behavior Search appears to treat any matching character sequence as a valid result without sufficiently prioritizing where that match occurs. For example, a search for: Wake should prioritize: Wake County Wake Forest High School Wakefield Middle School before records where the same sequence appears only later within the value. Likewise, an exact match should always rank above a partial match. Preferred Search Logic Console search should rank results using a predictable relevance hierarchy. Recommended order: Exact match Exact identifier match Starts-with / prefix match Word-boundary match Relevant partial match General substring match Substring matching can remain available, but it should be the lowest-priority matching method rather than the primary ranking behavior. Operational Impact Poor search relevance increases administrative effort when locating known records. This can affect searches for: users; groups; schools; policies; devices; categories; Access Lists; synchronized objects; other administrative records. Administrators often already know the beginning or exact value of the object they are trying to locate. In those cases, the console should prioritize the most probable intended result rather than presenting loosely related substring matches first. Requested Enhancement Update console search behavior so that results are ranked by relevance. At minimum: exact matches should rank first; prefix matches should rank ahead of internal substring matches; searches for complete identifiers should return the matching object prominently; broad substring matches should remain available after higher-confidence results; the ranking behavior should be consistent across console areas using the same search component. Optional Search Controls If Lightspeed intends to preserve broad substring matching as the default behavior, support for simple search controls or syntax would also address the issue. Examples could include: exact-match search; starts-with search; quoted search terms; field-specific search; search operators. Advanced syntax is not required if the default ranking behavior itself is corrected. Consistency Requirement Where the same search component is used across multiple Lightspeed Filter console areas, the matching and relevance logic should behave consistently. An administrator should not need to learn different search behavior depending on which console page is being used. Requested Outcome Provide console search behavior that prioritizes the record an administrator is most likely attempting to locate. The goal is not to remove partial search capability. The requested model is: Exact and prefix matches first → broad substring matches afterward rather than treating all substring matches as similarly relevant. Acceptance Criteria This request would be considered addressed when: Exact matches appear before partial matches. Prefix matches appear before internal substring matches. Search results are ordered according to relevance. Known identifiers can be located without reviewing unrelated substring results. Search behavior is predictable and consistent across applicable console areas. Broad substring searching remains available without reducing the visibility of stronger matches. Business Value Improved search relevance would: reduce time spent locating administrative records; improve console usability; reduce unnecessary search retries; make troubleshooting more efficient; improve consistency across administrative workflows. The requested change is fundamentally a ranking improvement: Prefer the strongest match, not merely any match.

With the new layout and view, it is incredibly bright. It would be nice to have an option for a dark mode or a way to invert the colors to make it easier on the eyes.

Issue The current Telemetry Report has two limitations that significantly reduce its usefulness in a large enterprise environment: CSV export is limited to approximately 50,000 devices. Administrators cannot sufficiently scope the report by location or similar organizational criteria before export. For an organization with a device population larger than the export ceiling, this prevents administrators from retrieving the complete Telemetry dataset. At the same time, the lack of granular filtering prevents administrators from isolating a smaller operational scope, such as a specific school, when troubleshooting deployments or agent-health issues. Operational Impact These limitations make it difficult to use Telemetry for proactive device and agent management. Examples include: validating an agent deployment at a specific school; identifying devices at one location that did not receive an update; comparing agent versions across locations; isolating a suspected deployment issue; reviewing agent health for a particular organizational group; exporting the complete district fleet for reconciliation or analysis. At WCPSS scale, the current 50,000-device limit means a full-fleet export is not possible. If administrators also cannot narrow the report sufficiently before export, there is no practical way to retrieve either the entire environment or a targeted operational subset. Requested Enhancement WCPSS requests that Lightspeed address one or preferably both of the following areas. Remove or Increase the Export Limitation Allow administrators to export the complete Telemetry result set. Possible implementation methods could include: removal of the 50,000-record ceiling; significantly increasing the limit; asynchronous report generation; paginated export; multiple-part CSV generation; another supported method for retrieving the entire dataset. The specific implementation is flexible as long as administrators can retrieve the complete report. Add Granular Report Filtering Allow Telemetry to be filtered before export using meaningful organizational and technical attributes. At minimum, WCPSS requests filtering by: school/location; organizational group where applicable; operating system; agent version; last check-in or reporting status. Location filtering is particularly important because it allows administrators to isolate a school-specific deployment or health issue without processing the entire district dataset. Preferred Behavior Administrators should be able to perform workflows such as: Location: School A Operating System: Windows Agent Version: Below current version and export only those matching devices. Alternatively, an administrator should be able to select: All Devices and retrieve the complete fleet without the report being truncated at 50,000 records. Export Transparency If an export is subject to any limit, the console should clearly indicate: the total number of matching records; the number of records included in the export; whether the export has been truncated. Administrators should never have to determine after the fact that a dataset was incomplete. Requested Outcome Make Telemetry reporting usable at enterprise scale by providing either: complete fleet export capability; sufficient granular filtering to retrieve targeted datasets; or preferably both. The preferred model is: Filter to the operational scope needed → export the complete matching result set while still retaining the ability to export the full fleet when required. Acceptance Criteria This request would be considered addressed when: Administrators can export more than 50,000 Telemetry records or otherwise retrieve the complete matching dataset. Telemetry can be filtered by school/location. Additional useful filters such as operating system, agent version, and last check-in are available. Applied filters are respected by the export. The interface clearly identifies when an export is incomplete or limited. Administrators can isolate a location-specific deployment or agent-health issue without manually processing the entire district dataset. A complete district-wide dataset can be retrieved when required. Business Value This enhancement would: make Telemetry usable at large-district scale; improve deployment validation; support proactive agent-health analysis; reduce troubleshooting time; allow school-specific investigations; improve reconciliation with asset and endpoint-management data; prevent administrators from relying on incomplete exports. The core requirement is: Telemetry should support both the size of the organization and the ability to narrow the data to the scope being investigated.

Issue WCPSS supports Lightspeed's planned Access Scan capability that will allow users to submit content to the Lightspeed Content team for review. Access Scan can already be used contextually from the browser, including while a teacher is viewing YouTube. The primary usability concern is the requirement to manually enter a student email address as part of the Access Scan workflow. For a teacher who simply wants to determine whether instructional content is accessible to students or submit that content for review, requiring a specific student email creates unnecessary friction. Operational Impact The student-email requirement creates several problems: teachers must know or locate a valid student account; the workflow becomes dependent on a specific student identity even when the teacher is evaluating content for an entire class; users may repeatedly enter the same or arbitrary student account simply to perform testing; the additional step discourages use of an otherwise convenient review tool; it complicates what should be a quick instructional-content validation workflow. The request is not to remove identity-aware testing where it is necessary. The goal is to avoid requiring manual student identity entry when the district's managed environment can provide sufficient context automatically. Requested Enhancement Allow Access Scan to determine the appropriate student filtering context without requiring the user to manually enter a student email for every scan or review request. Potential approaches could include: Managed Default Test Profile Allow district administrators to configure a default student test context for Access Scan. For example: Default Access Scan Context: District Student Baseline Policy Teachers could scan content against that configured context without selecting an individual student. Organizational Unit or Policy Selection Allow users to select an approved student scope such as: Elementary Students Middle School Students High School Students specific school or Organizational Unit designated Filter policy This would often be more meaningful than selecting an individual student account. Automatically Assigned Context If Access Scan is deployed through a managed Chrome extension, district configuration could provide the appropriate test policy or student context automatically. The user would simply select: Scan with Access Scan and the extension would evaluate the content using the district-defined student context. Remember Previous Selection If a specific student or policy must still be selected, Access Scan should at minimum remember the user's previously selected context so it does not need to be entered repeatedly. Preferred Workflow The desired experience is: Teacher encounters instructional content. Teacher opens Access Scan. The district-defined student context is already selected. Access Scan evaluates the URL. If necessary, the teacher submits the content for Lightspeed review. No manual student email lookup or entry should be required during the normal workflow. Identity-Aware Testing There will still be situations where testing a specific student account is valuable. Access Scan should retain an optional capability such as: Test as specific student for troubleshooting individual policy or assignment issues. However, this should be an optional advanced workflow rather than a mandatory step for every content scan. Google Admin / Managed Extension Integration Because Access Scan can be deployed as a managed browser capability, Lightspeed should consider supporting administrator-configured defaults through managed extension settings. District administrators could define: default student policy; default Organizational Unit or group; permitted testing contexts; whether users may select individual students; whether review submissions are enabled. This would allow the extension to inherit appropriate district configuration automatically. Least Privilege Access Teachers using Access Scan should not require Lightspeed administrative-console permissions. The extension should provide only the functionality necessary to: evaluate content against an approved student context; optionally select another authorized context; submit content for review. Administrative policy management should remain separate. Requested Outcome Streamline Access Scan so routine instructional-content testing and review submission does not require manually entering a student email address. The preferred model is: Open Access Scan → district student context is already known → scan or submit rather than: Open Access Scan → locate and enter a student email → scan → repeat for the next request Acceptance Criteria This request would be considered addressed when: Access Scan can operate without requiring manual student email entry for routine scans. Administrators can define a default student testing context. The default context can represent a policy, group, OU, or equivalent student scope. Users can optionally test a specific student when individual troubleshooting is required. Managed extension settings can supply the appropriate district context where technically possible. The selected/default context persists between scans where appropriate. Review submissions can use the same resolved student context without requiring the teacher to re-enter identity information. Business Value This enhancement would: reduce friction for teachers; increase adoption of Access Scan; reduce reliance on arbitrary student accounts for testing; speed instructional-content review; reduce Help Desk involvement; make the upcoming SmartPlay review workflow significantly more seamless. The key improvement is straightforward: Access Scan should know the student context without requiring the teacher to supply a student email every time.

Grade to Year, District to Organisation/Local Authority/Trust, Student to Pupil. As a UK school, district and grade is not the best and gives the impression that Lightspeed is only catering to the US market. For added points let us rename the "grades" or even better use the custom ones from our MIS "Year 8", "Upper 6th", "Prep 5" etc...

Please include more details in the reply messages we get back from support on a case we have submitted. If I have several cases going and I only receive a case number, I have no idea what support is referring to. I have to go to my support cases webpage and find the case number to see the details. Even if just the Title/Subject of the case submitted were included in the reply messages, it would be so helpful!

I used to be able to open a new tab and look at two of the different districts I manage at the same time. This is very useful when troubleshooting an issue that is happening in one district but not another. At some point all open tabs to the portal will refresh to whichever district I selected most recently in any tab. This has caused a lot of friction and I'd like to be able to compare side by side without having to use different browsers or private browsing

Please add the ISTE Seal to the Third Party Reviews options. https://iste.org/iste-seal