The best model I can think of would be to allow the creation of custom roles where Account-level, Global client-org, and Individual client-org permissions can be individually assigned to the role. Allowing the use of custom role names could allow integration with SSO so that IdP group memberships can automatically determine roles and permissions.

Our org is deeply invested in Entra as our IdP so using our existing Entra group memberships to assign roles and permissions in Huntress would be the ideal solution. Even better if SSO could automatically provision/deprovision users so we can manage identity solely in our IdP during user on/off-boarding.

It's common for c-staff to request access to things like Huntress, especially if they get copied on alerts. SSO would at the client-org level would be great. This could allow us to automate creating organization users and granting them permissions based on Entra group memberships. It could be easily integrated with the M365 tenant mapping process.

Granular permissions are really needed. As others have commented, we need the ability to assign part of our MSP team with the ability to manage some items (isolate, de-isolate, Defender exclusions) for every client individually, but not globally.

As others have said, the ability to granularly assign permissions is very much needed. The "Security Engineer" role as it stands today is too permissive.

We would like to be able to disallow account-level access changes for Account-level users (example, not be able to set an exclusion for a country...for ALL organizations), or maybe even allow ONLY user-level access changes for Account-level users (our technicians who currently have the "Security Engineer" role). Another way to put this is: We need the ability to granularly assign permissions per role. In addition, adding the ability to granularly assign organization-level permissions (for internal IT users at the larger clients) so they can do things like set travel exclusions for VPN/Location Escalations for their org, for example.

Feedback from a partner we recieved:

I know Huntress has been talking about removing the Security Engineer role completely for Organizational level, but maybe that should be the equivalent of the current admin role, while the admin role is modified to actually allow for all actions. I'm unclear as I don't believe I've run into this issue before, for most clients we do the management of the escalations at the account level, but I would still expect that if I make an internal organization's power user an admin for the organization it would still allow them to resolve escalations. Otherwise, I'm not sure what the point of that role would be? For that client specifically, they found that new VPN connection was unexpected, but they were unable to create a new ITDR rule to effectively take action on the alert.

We need roles for different techs to manage different companies

We need Finance Role to be allowed to sync subscriptions so they can update Agreement qty. and manage agreements. Since this is not enabled, it forces an admin to intervene during the billing process due to lack of permissions.

We need the ability as an MSP to set Account users to access a subset of organizations. AutoElevate has a feature where we can say "This user can access all organizations EXCEPT [list one or more organizations in the account]". We don't want our regular techs being able to affect our internal systems but be able to affect our clients.

There needs to be a security level or option that gives a user the ability to do MS integrations for MDR without having admin access. Staff who do level 2 provisioning should not have access to billing information or be able to sign contracts on behalf of the company - these should be only available to owners/managers.