Users and Access
Insights has no user management screen. Users, their status, and their device group access are all set in the Administration module of SIP. Insights reads what SIP sends, and enforces it.
Where users come from
Users are created in Administration, under Access > Users. A user account carries a username, an email address, a first and last name, and an enabled or disabled status.
A SIP user account can be disabled but not deleted. Deleting a user would take their audit history with them. Disabling keeps the record and removes their access to SIP.
Insights learns about your users two ways, and the difference matters when someone reports a problem.
The user sync creates the authorization record. Your SIP sends its users across as a batch, and Insights stores each one's SIP user ID, email address, authorized device groups and enabled status. Every access decision is read from this record. It isn't an account anyone can sign in with.
Opening Insights from the module menu creates the account. The Insights sign-in account is created the first time that person chooses Insights from the SIP module menu, and not before. Someone who has been synced but has never arrived that way is known to Insights for access decisions, but has nothing to sign in to. Signing In covers that first arrival.
What decides what someone sees
Permissions in SIP are granted through user groups, not to individual users. A user group is a set of users with the same permissions, assigned at the group level under Access > User Groups. A user's own page only says which groups they belong to. Part of what a group grants is a set of device groups: all devices, or named ones.
That set is the only access decision SIP passes to Insights, alongside whether the account is enabled. Insights applies it everywhere:
- The device group selector lists the groups the user is authorized for, not every group that exists. Two people at the same company can open the same page and see different lists and different numbers.
- Every request for a metric, a device list or a control result is filtered to that same set before anything is returned.
- The MCP server uses it too, and refuses any device group outside it.
Almost every figure in Insights belongs to one device group, so this setting shapes everything a person sees. Device groups explains the scoping.
To change what someone sees, change the device groups on their user group in Administration. The new list reaches Insights at the next user sync, or straight away if they open Insights from the module menu again. Insights caches the result briefly, so wait a couple of minutes before deciding nothing happened.
A user with no authorized device groups
They can sign in and see nothing. The device group selector is empty, and every page scopes itself to the selected group, so the pages have nothing to show. It looks like missing data, but it is missing authorization.
Over the MCP server, the same account is refused outright, with 403 SIP user has no authorized device groups.
Add them to a user group that authorizes at least one device group.
When someone should have access and does not
Insights checks two conditions, in this order, and each one has its own fix in Administration.
Insights has never been told the user exists. The account has to be in the record SIP syncs across. A user created in SIP moments ago won't be there yet.
The account has no authorized device groups. Covered above: add them to a user group that has device groups on it.
If the person can't get as far as signing in, the cause is usually a different one. Signing In lists those, and Troubleshooting covers the rest.