Filter

District would like to have the option to enable an email notification that would be sent if a sync (from any source) into Platform fails.

Issue Access Scan currently requires a teacher to manually enter a student email address to test how a website or resource will behave for students. While student-specific testing is useful for troubleshooting individual issues, it is unnecessarily tedious for routine instructional use. Most teachers are not trying to determine whether a resource works for one specific student. They are trying to answer a much simpler question: Will this resource work for students in this grade? Requiring an individual student email adds unnecessary steps to what should be a fast validation workflow. Requested Enhancement Add a simple grade-level dropdown to Access Scan. For example: Test Access For: Kindergarten Grade 1 Grade 2 Grade 3 Grade 4 Grade 5 Grade 6 Grade 7 Grade 8 Grade 9 Grade 10 Grade 11 Grade 12 The teacher selects the grade they want to test, and Access Scan evaluates the requested URL against the Lightspeed policy associated with that grade. There is no need for Lightspeed to determine which grades the authenticated teacher personally teaches. Providing all configured grade levels keeps the solution simple, predictable, and broadly useful. Policy Resolution Lightspeed already receives organizational and policy data through Data Sync. District administrators should be able to associate each available grade selection with the appropriate student filtering policy. A simple model could be: Grade Selection → Mapped Student Policy → Access Scan Result For example: Grade 6 → Middle School Student Policy → Allowed / Blocked Result This avoids requiring a real student identity when the objective is simply to test policy behavior. Preferred Workflow The desired workflow is: Teacher opens Access Scan. Teacher enters or scans the instructional URL. Teacher selects a grade. Access Scan evaluates the URL against the policy mapped to that grade. The result is returned immediately. No student lookup is required. No student email needs to be copied or entered. No administrative console access is required. Specific-Student Testing Should Remain Available The existing student-email option should remain for cases where an administrator or teacher needs to test the experience of a particular student. Access Scan could therefore provide: Test Against: Grade Specific Student The grade option supports routine instructional validation. The specific-student option supports individual troubleshooting. Administrative Configuration District administrators should be able to configure: which grade levels appear in the dropdown; which filtering policy is associated with each grade; whether grade-based testing is enabled; whether specific-student testing remains available; which users may use Access Scan. This keeps policy mapping under district control while keeping the teacher experience simple. Least Privilege Access Grade selection should remain a read-only testing capability. Teachers should not receive: policy editing rights; Filter administrative access; access to policy configuration; additional administrative privileges. They simply select an approved grade context and receive the resulting access determination. Requested Outcome Allow teachers to test a website against a grade-level student policy without first locating and entering a student email address. The preferred model is: Open Access Scan → Select Grade → Scan → Result rather than: Open Access Scan → Find a Student → Copy Email → Enter Email → Scan This would make instructional resource validation dramatically faster and more practical for classroom use, providing teachers with useful answers at — dare we say — Lightspeed. Acceptance Criteria This request would be considered addressed when: Access Scan provides a grade-level dropdown. All district-configured grade levels can be presented without requiring Lightspeed to determine the teacher's individual teaching assignment. Each grade can be mapped to an appropriate Lightspeed filtering policy. Teachers can test resources without entering a student email. Specific-student testing remains available for individual troubleshooting. Grade-based testing does not grant policy-management or administrative access. District administrators control the available grades and policy mappings. Business Value This enhancement would: significantly reduce teacher effort; make Access Scan practical for routine classroom preparation; eliminate unnecessary student-email lookup; encourage proactive testing of instructional resources; reduce avoidable Help Desk requests; preserve student-specific testing where needed; leverage policy information Lightspeed already maintains; provide faster, more actionable information to instructional users. The principle is simple: If the goal is to test a grade-level policy, require a grade — not a student.

Lightspeed Filter’s current agent diagnostic process is technically valid for deep engineering troubleshooting, but it is too manual and intrusive to serve as the primary support model for a large K–12 environment. Current procedures can require stopping and restarting the Filter Agent, changing service parameters or environment variables, editing macOS launch-daemon configuration, enabling Chrome extension Developer Tools, reproducing the issue locally, and manually retrieving logs. Those steps are more appropriate as Tier-3 escalation procedures than routine enterprise support. The strongest comparison is Zscaler Client Connector, a direct competitor in endpoint web/security enforcement. Zscaler already provides a more mature supportability model with built-in Export Logs, Report an Issue, controlled diagnostic log modes, automatic return to the organization’s default logging state, automatic log attachment to support submissions, and an optional Auto System Info and Log Fetch capability for support-side retrieval. This demonstrates that a commercial endpoint filtering/security platform can provide structured, controlled diagnostics without requiring administrators to manually manipulate the enforcement service for normal troubleshooting. We are requesting that Lightspeed implement a comparable enterprise diagnostic model: a standardized support bundle, time-limited diagnostic sessions with automatic rollback, better centralized visibility into agent health/policy/identity state, and ultimately administrator-initiated remote diagnostic collection from the Filter console. The requested end state is straightforward: An authorized administrator should be able to select a user or device, start a scoped diagnostic session, reproduce the issue, and securely collect or submit the resulting support bundle without manually changing services, plist files, environment variables, or Chrome Developer Tools settings. Manual low-level procedures should remain available for exceptional engineering cases, but they should not be the normal prerequisite for obtaining actionable Filter Agent diagnostics.

It would be nice to have the ability to disable the Smart Agent on a device for either a set amount of minutes or until turned back on. This would help with troubleshooting filtering issues since the web activity log takes a bit of time to show results.

I get so many release notes emails for aspects not relative to us, such as we don't use ChromeOS so these emails are not relevant to us. Our DSLs would like to know about Alert updates and features to ensure IT are staying on top of this but don't want to know about Filter update, Extension Helper version updates or Release Candidates etc. Could you please put a way of signing up to the specific release updates relevant to the role and just what we want to be notified on, instead of bombarding with all releases for everything?

We use SCCM to deploy the filter agent. On uninstall of the old agent a forced reboot with no notification is done. This is very problematic as it can happen while people are using their machines. Mostly laptops so I can't deploy at night as they might not be in the office. If a reboot is required then a notification to reboot at the least is ideal.

Suppress the reboot for agent updates for Filter on Windows - For example: scheduling options can be done on the sccm side for manual update // however, if we want to use auto update function within Lightspeed, it would be ideal to be able to either schedule the reboot/update or to select/target specific groups one or a few at a time.

Could the ability to auto update the current Filter Agent be made to push from sub-sites instead on hitting all devices. With the need of testing before mass updates, we'd like to be able to test agent versions without making it available to all or using a different deployment method.

Add support for nesting of AD groups so that they are imported and recognized by the filter. The ability to apply policies to a "group of groups" is fundamental in MSAD. It simplifies organization by removing the necessity of manually keeping several groups updated.

I have separate lists of allowed sites for testing, lecture, and independent work. However, if students have downloaded an app, I can't see it. I have seen students play games on their Chromebook but I can't view it or close it. Students have access to the Gemini App even though I don't have it allowed.