As Immy has evolved for us, it is now used by everyone in the business. But I and a handful of others are still the only users with permissions high enough to create, edit or delete deployments.
Ideally, we want technicians to have the ability to edit deployments, mainly just the parameters. For instance, Sophos Endpoint, our customers time to time will upgrade to a higher tier for more protection and that will require additional features be checked on the deployment.
What takes 2 seconds to update, can take hours / days depending on when one of us with permission has time to look at it. Where a tech with the actual ticket to perform the upgrade could also just do it in 2 seconds.
Can permissions finally be reviewed? It’s something that has been asked for a lot, always told “it’s coming” but here we are
If you wanted to get super fancy, maybe even just certain tasks have access to be modified by lower permission tiers, but even the former is sufficient for us.
I’d like to see this prioritized over other new features. For our company this is preventing us from giving all our technicians access to Immybot or some of our customers. For years we have been told “its coming” but all we have so far is user or full admin and instead new features are prioritized.
I think its perfectly acceptable to have a permission system and say its still a work in progress and there may be issues with it currently.
A little disheartening to see this has been planned for almost two years now with no updates, this would really benefit us. We are currently on the starter plan and already having talks to move up to using Immy to do more and moving to the full plan, but we’re pretty restricted with how we can do that until we get better permission options.
This feature is actively being developed. We plan on fully implementing RBAC (Role-Based Access Control) behind the scenes over the current system before allowing customers to create their own custom roles. This means that initially, we’ll have a handful of built-in roles (MSP Admin, MSP User, Tenant Admin, Tenant User, etc) being used behind the scenes that map to the permissions a user currently has today.
The scope-based permission part is already being used in the current release. e.g. A user with this role can manage software, run maintenance sessions, manage system preferences, etc.
We are now focused on the “resource” based side of permissions, where we want to allow access to a subset of resources. e.g. Custom Role that allows a user to manage only workstations and laptops (no servers or domain controllers) from customer A and customer B.