Feature Requests

Description: The search feature in the Universal List currently only searches the “Value” column (domain name). We’d like search to be expanded to also include the “Notes” column. Use case: Admins often use the Notes column to record context about why a domain was added, such as the requester, the related ticket, the application it supports, or the date it was approved. As allow and block lists grow, admins need a way to find entries based on that context, not just the domain itself. Today, the only workaround is using the browser’s Ctrl+F, which only works on what’s currently loaded on the page and isn’t practical for large lists. Proposed solution: Include the Notes column in Universal List search results, alongside the Value column. Optionally, allow users to choose whether to search by Value, Notes, or both. Impact: Faster auditing and cleanup of large allow and block lists. Easier troubleshooting when admins need to find all entries tied to a specific application, request, or ticket. Less reliance on external tracking or browser workarounds.

Would like Connectwise / ScreenConnect to be able to be blocked as a Remote Desktop Tool in App Aware: September 8th Screen Connect 9.9 CWE: https://www.connectwise.com/company/trust/security-bulletins/2026-09-08-screenconnect-bulletin Missing Patch warning: https://www.bleepingcomputer.com/news/security/connectwise-warns-of-new-screenconnect-flaw-without-patch/ Actively Exploited attacks: Critical ScreenConnect flaw now actively exploited in attacks CISA Advisory: https://www.cisa.gov/known-exploited-vulnerabilities-catalog SentinalOne Remote Code Execution: https://www.sentinelone.com/vulnerability-database/cve-2025-3935/

Allow the ability to add multiple email addresses for the notice email when a end user requests access to a domain. Specifically talking about under Policies > Block Pages > Notice Email. Use case here is when we have a co-managed client and we want the request to come to us (the MSP) and the customer's IT staff as well.

The ability to set a custom block page message instead of the default: "If you feel you've reached this page in error, please click here to notify the network administrator."

Add an option to restrict end-user allowlist requests to domains that are Uncategorized / Not Yet Categorized. If say a blocked domain already has an assigned category [ex- Gambling, Malware, Social Networking, etc], users should not be presented with the option to request that domain be allowlisted/whitelisted. This would allow admins to enable self-service requests for potentially miscategorized or newly discovered websites without generating requests for sites intentionally blocked by an existing category policies.

We should be able to give a site or agent a Policy, that policy should be able to just inherit another policy, using whole policy chain before it and over riding all prior policies - this allows us to do a BLOCK ALL (or strict default policy), and on a selective basis, allow more freedom - so in our example, we would want "WHITELIST ONLY" for the whole site, and then 3 in mission critical sites available for one policy + the whitelist only, then the second policy will be mission critical + whitelist, but would allow us to say trusted user, can access a few more less required sites

When we allow a domain at the site level, we attach a ticket number to the description field so we can validate where the allow request originated. When that parent domain asks if you would like to add a CNAME that is associated, it does not allow us to duplicate the description for the parent domain, edit the description thereafter nor point back to the parent domain in any way. This leaves us with domains in our allow list with no description nor an easy way to explain the allow to management and/or customers. Requesting any of the following: 1. Just duplicate whatever is in the description field for the parent domain when adding the CNAME from the pop-up in Policy->Allow Lists->Add Domain(which causes a popup for an additional CNAME). 2. Have the CNAME point to the original domain it initiated from in it's description. (just the parent domain in the description field surrounded by a delimiter like brackets[] to show how it was added is fine) 3. Allow description editing of the allowed/blocked list items in the policy. This should probably be its own suggestion as it would be helpful outside of this request.

We have issues where CNAME's that don't display a website, such as a redirect for email services like Sendgrid, have a category of 'landing page' which we block. This results in inacurate blocks, as the underlying service is legitimate, but the CNAME has a different category.

Currently, when someone hits a block page, we show the domain they requested; but it may actually be the case that this domain points to a CNAME of another domain, and that is the domain in question being blocked. We should in that case show the CNAME expansion, and which domain is actually blocked; to reduce confusion.

Provide the ability to block DNS requests if the domain's destination IP address belongs to a specific country. Allow customers to decide which countries are blocked/allowed in the Dashboard.