How to create a separate views for groups?

I'm only addressing one aspect of this post.  How to use a single view for all of the groups, but still see somewhat customized content.  And really there are several ways, I'll be showing just one.

Add a "Custom Query" widget to the view.  There is a variable ${ID} that holds the group id of the current group you are viewing.  You can use that in the custom query to get what you are looking for.

Example Query:

Select

    N.Caption as Device,

    '/Orion/images/StatusIcons/Small-' + n.StatusLED as _IconFor_Device,

    n.DetailsURL as _LinkFor_Device,

    n.IP,

    N.ResponseTime

From Orion.Nodes N

Inner Join Orion.ContainerMembers cm on cm.MemberPrimaryID = N.NodeID

Where

    cm.ContainerID = ${ID}

This example will work for Poll01 vs Poll02, it does not work for using Groups of groups in a hierarchy, where you want completely different information on the page for the parent vs the child groups.  That will get more complicated and I'll have to think on it for a bit.  Maybe someone else has already done it.

Oh nice, I didn't know I could do that with SWQL. Though, I'm still in the learning stage of running SQL and SWQL queries. Now, I wonder how I can make that work with an Orion Map. I'm wanting each Poll to have it's own topology map when it clicked on. I have no idea how to make that happen but you got my gears turning now.

Thank you!

Ok, slightly off topic, but possibly relevant to you.  CUSTOM PROPERTIES TEES Tees tees ... <echos off in the distance>

I am a huge advocate of custom properties.  Your example above is about the better examples of using groups, but generally I hate groups in Orion.  Even when I use groups, they are just a dynamic query for a custom property.

For example in your setup.  I would add a custom property on nodes called "Poll" that would be the number.  Then the group Poll01, would be dynamic query where the custom property "poll" is 01.  Now you can use either the custom property or the group, whatever fits your needs at the moment.

Custom properties are 100% easier to use in alerts, reports and generally any SWQL query.

Man, I got a lot to learn about NPM. Seriously, Thank you!

Does anyone later go back and reread your post because you can't remember if you typed advocate or avocado, because I was thinking about food.  My brain even goes one step farther and type advacato, but since it's got the red underline, my brain goes hey maybe I don't know how to spell that, lets use another word.... guacamole.  Yes, that sounds delicious, "I guacamole custom properties". 

Today is not Taco Tuesday, it's Thirsty Thurday....FOCUS, Brian Scott!

I agree that Custom Properties would likely be a better fit in this case.  It would still allow you to logically "group" or separate data, better in reporting and alerting scenarios, as well as make it easy to build Orion Maps because you have filters to easily obtain specific entities and add them to a map.  Once you have built a view, you could copy it, and then just filter the view or the widgets on Custom Property 2, 3, and so on. 

If you really want to get into the weeds of the back end terminology, its a legacy thing.  See if you can dig up screenshots of NPM 10.0 and such and the terminology being used more closely tracks with how the UI worked at that time.  When you spend time in the DB the answer to almost all of the "this doesn't add up" is usually that it did when that feature first came into existence and nobody wants to go back and refactor all the names of the columns or table arrangements for the later adjustments unless there turns out to be a serious show stopping bug in the older structures.

To your real problem, it looks like several others have chimed in with functional work arounds that are pretty much the way I would do it as well.  I often think that Orion new users would be better off if instead of getting sent to the Discovery as soon as you first load the tool up it should take you to the custom properties and tell you "this is the most important foundational element of the whole thing"

Also,

ADDING CUSTOM TABS TO THE TOP LEVEL NAV BAR with the API

*totally not supported, back up your DB before you try anything but I use this tool with every client I touch these days.

create active directory groups > put people in the correct groups > make view limitations for each group. Done