Can you elaborate on the mess?
A mess is giving 100 people access to things they can break.
So, have you defined what access these 100 people need?
Do they need to add nodes? Delete nodes? Create views, alter thresholds? Change the main front UI page? Add users?
What modules do you have?
The modules that we have are SAM, NPM, and Netpath. I guess determining what they need would be the first step, but I know they do not need access to view all of the servers in our SAM inventory, so I am trying to figure out how to give them what they need. I am trying to figure out best practice as it relates to giving users access to different groups and views.
Go to Admin / Settings / Manage accounts and Edit a GROUP or USER.
Go to Account Limitations - set filters for what they should see here.
Also, you can create a custom View for each group or users in the option - Home Page View.
Go to manage Views, make a copy of a View you like, customize it, then assign the copy with a Filter to your GROUP or USER.
I would say that, to me, the best practice is not to assume that you need to use account limitations on most accounts. I build dashboards (which are pretty easy to script out and deploy in bulk) with filters on the views themselves so that a team can see what is related to them, but I rarely bother restricting their actual account because that introduces more headaches than it solves in my experience.
Is there a business case for why it would be damaging for someone who wants to see the cpu load history of a node they don't directly manage? If they don't get anything from seeing it then I bet that they just never click on the nodes they don't need and its already a non-issue. Is there a value-add to the business of your spending the man hours to figure out a mapping of every user group (even worse if you are doing it per individual user) and exactly which servers they do and don't need to see and then keeping that list up to date as new servers spin up in the future?
There is not a slick easy way to automatically and continuously update the list of users and account limitations so you are asking to take on a work load that will take a bunch of babysitting and frequently communicating back and forth with all the teams in your org whenever something changes on their end, and yields very limited (possibly none?) improvement to the operations of the business. The ROI on that effort is pretty bad unless you work in a hyper secure environment where knowing about the existence and name of someone else's sql database poses some kind of risk.
If you had NCM I would say lock it down to where only the network team sees their network configs but with just NPM/SAM, seeing that a switch port has low utilization could save the server admin from even trying to bug the network team about the slow connection they are noticing between a pair of servers so they can focus on the application issues they have. Maybe two admins are collaborating on a new cross team project and they can't both see the same nodes now they need to reach out to you, gotta figure out which nodes they need, you have to edit their permissions so they can proceed with what they were working on, then they forgot to tell you about some other new server they spun up and also need so there is more emailing back and forth, more interrupting each other's work. And for what ultimate goal?
Aggregating info about your whole environment into the single place is one of the strengths of Orion, building silos within the tool undermines that value and potentially adds a lot of admin overhead for you.
We utilize active directory groups for the different departments (sysadmin, DBA, Network, App admins, management). Anyone outside of this is added as a single user with just the specific access that they require to do their job successfully.