Feature Requests

Inspector-level view permissions for all inspectors across all environments -Summary- Partners need to control who can view specific inspectors at a level finer than environment scoping. The control must apply to every Liongard inspector, including but not limited to Microsoft 365, AD, RMM, EDR, network, and custom inspectors. Goal: least-privilege visibility without disrupting existing setups. -Who this helps- MSPs with segmented teams, compliance-driven partners, and any org that must restrict access to sensitive tenant or system data while enabling appropriate visibility for delivery teams. -Problem- Current roles support environment-level scoping only. Partners require the ability to hide or allow individual inspectors by role within an environment. This gap is pausing POCs and extending security reviews. -Evidence from field- Active POCs have stalled on RBAC granularity. SEs report repeated requests for inspector-level controls across multiple system types, not just M365. -Proposed solution- Add an inspector-level “Visible to role(s)” setting for every inspector within an environment. Admins select which roles can view each inspector. Defaults preserve current behavior until changed. -Contact- Lamont Largie, Manager, Solutions Engineering SE team can provide partner scenarios and test cases.

Would like see an feature that will allows us to remove certain permissions from Roles assigned to users.

Description: Recommend implementing a built-in field in Liongard's Asset Inventory that displays the Windows version installed on workstations based on their OS.BuildNumber. This would provide partners with immediate visibility into the actual Windows version running on their devices—critical for patching, upgrade readiness, and compliance planning. Why It Matters: Partners often need to validate Windows 11/10 deployment status across environments. Current data (Build Number) is useful but not user-friendly for non-technical teams. This would eliminate the need to create a custom metric and make the insight more accessible in-app. Proposed Metric Logic: { "WindowsVersionInstalled": OS.BuildNumber == '26100' && 'Windows 11 24H2' || OS.BuildNumber == '22631' && 'Windows 11 23H2' || OS.BuildNumber == '22621' && 'Windows 11 22H2' || OS.BuildNumber == '22000' && 'Windows 11 21H2' || OS.BuildNumber == '19045' && 'Windows 10 22H2' || OS.BuildNumber == '19044' && 'Windows 10 21H2' || OS.BuildNumber == '19043' && 'Windows 10 21H1' || OS.BuildNumber == '19042' && 'Windows 10 20H2' || OS.BuildNumber == '19041' && 'Windows 10 2004' || OS.BuildNumber == '18363' && 'Windows 10 1909' || OS.BuildNumber == '18362' && 'Windows 10 1903' || OS.BuildNumber == '17763' && 'Windows 10 1809' || OS.BuildNumber == '17134' && 'Windows 10 1803' || OS.BuildNumber == '16299' && 'Windows 10 1709' || OS.BuildNumber == '15063' && 'Windows 10 1703' || OS.BuildNumber == '14393' && 'Windows 10 1607' || OS.BuildNumber == '10586' && 'Windows 10 1511' || OS.BuildNumber == '10240' && 'Windows 10 1507' || 'Unknown' } Value to Partners: Enhances visibility into OS lifecycle and versioning. Enables better planning for upgrades and patching. Reduces manual effort or need for external tools. Would love to see this added as a native column or attribute within the Asset Inventory for easy access and reporting.

Please, please consider reevaluating the behavior of the ENTER key on the edit page for Metrics. Currently, whenever pressed, it submits the Update button. The problem is, when using a column filter, many of us habitually press ENTER after typing in a keyword (as some of our other tools require this to execute the filter...). As you can imagine, it's a highly frustrating experience (with such a simple fix). :D

when we onboarded this platform we did not have a good understanding of how we wanted to go about with our naming convention. it is possible to rename "friendly name" however not "system". if we where to get the "system" name how we would prefer it to be, we would have to delete the record and re-add it, with a new name, and while doing so we will loose all historic on the record.please make it possible to rename the "system" field as well - introduce for your own sake a GUID or similar, instead of relying on the system name being hard coded :)with this option, it is possible for us to better clean up our dashboard, as well to view records within each inspector

Can you give us a report of potential duplicate Inspectors? You could make assumptions if they're duplicates & we can say if its true or not but at least we know

Ability to Add Attachments in Notes, to be able to share documents for more visibility.

Would like to see an option to see the total captured changes across ALL Environments in the dasboard just like we have for Alerts and Auto-Discovered Systems.

We would like to have the ability to create custom configuration types using the broad amount of data that the inspectors collect to better advance our MSP Documentation. For example: We could create a custom config type for our RDS Licensed Users and keep a configuration that records all the users in a specific AD group for Microsoft SPLA Licensing Audits.Another example, is my SQL team would like a custom configuration type using the SQL Inspector information to outline the SQL Advanced Parameters for specific servers and have it documented.

It would further secure access to our data. By limiting this we can ensure the integrity of our Liongard portal even if a password is stolen.