That's a very 'it depends' kind of question...
Your best bet would be to map out a schema on the whiteboard and envision who needs to see what. Once you get that down, I would try and identify something about the nodes that makes them stand out. You will want to make a custom property on this.
For instance, I have seen before something like this:
Departments: A, B, C ,D
Users: 1, 2, 3
User 1 needs to see only A
User 2 needs to see A and C
User 3 needs to see A,B,C,D (everything)
So, you create groups/accounts for each user set.
Then you assign a custom property field to all nodes named 'Department'
Then, you populate the nodes with what departments use them (ie, shared switches will get more than one value)
Now, you create account limitations on the groups to allow them only to see certain nodes like this:
User 1 Limitation:
Department = A
User 2 Limitation:
Department IN ('A','C')
User 3 Limitation:
Department IS NOT NULL
As you can imagine, there are hundreds of possibilities here. (and definitely more than one way to get the same results) You can limit on multiple fields as well, even down to the interface level. This should get you in the right direction though.
As far as 'best-practice'; I would always stick with "least-privileged access"
Thank you Zackm.
I was thinking about something like this or 2 custom props
That confirms my idea.
I'll organize who needs what and then create acces
we have a similar problem in that multiple vendors support the same node. (e.g. L2 vs L3). so we want to setup two custom properties L2Support and L3Support. I was wondering if the account limitation builder would allow to us to do something like
L2Support or L3Support = CompanyA