Managing your account › Managing users and permissions

Managing users and permissions

Note: Some Gridium accounts do not yet have user management features enabled. If you’re looking for these settings but they’re not available, please contact support@gridium.com.

The account users and building users pages let you control who has access to your Gridium account, what they can do, and which buildings they can see. Account admins can manage all of this account-wide. Full users can adjust permissions for the individual buildings they have access to.

This page covers the user roles available, where to manage user access, how permissions work at the building level, and how to use regions to apply permissions across multiple buildings at once.

User roles

Each person on your account has a role on each building, plus an optional admin flag at the account level. Roles are set per building, so the same person can be a full user on one building and a viewer on another.

Viewer. Read-only access to a building’s data. Viewers can see usage, costs, reports, and load curves for buildings they’re assigned to. They can also create load curve notes, since adding context to data isn’t considered a settings change. Viewers cannot modify building settings, manage other users’ access, or invite new people.

Full user. Read and modify access to a building’s data. Full users can see everything a viewer can see, plus change building settings (such as occupancy, square footage, and operating hours), manage user access for that specific building, and invite new people to it.

Account admin. Granted at the account level rather than per building. The admin flag is independent of building permissions: an account admin’s access to any individual building is whatever role they’ve been assigned there. What admins can additionally do is:

  • Change account-wide settings, including the user approval settings on the Security tab.
  • Add, remove, and edit any user on the account.
  • Approve or deny pending invitations.
  • Create and manage building groups.
  • View the full audit history for the account.

An account can have any number of admins.

Where to manage users

Two pages let you manage users, depending on how you’re thinking about access:

  • Account users page. Lists everyone on the account and lets you see and edit their roles across all buildings at once. Open it from the account settings menu (gear icon) and click the Users tab. Account admins can edit the full list. Full users can see the list but only edit users on buildings they have access to.
  • Building users page. Lists everyone with access to a single building. Open it from the building info section. Useful when you’re focused on one building and want to see exactly who has access to it.

Both pages let you start an invitation. For details on inviting a new person, see Inviting users to your account.

Setting permissions

A user’s role can be set at three levels: All buildings, on a region, or on an individual building. When you open someone’s permissions list, you’ll see all three levels stacked together, with All buildings at the top and individual buildings nested under any regions they belong to.

To change someone’s role at any level:

  1. Open the user’s profile from either the account users page or the building users page.
  2. Find the level you want to change in their permissions list (All buildings, a region, or an individual building).
  3. Choose the role you want: No access, Viewer, or Full user.
  4. Save your changes.

Updates take effect immediately for every building covered by the level you changed. The same user can have different roles at different levels; how those combine is described in the next section.

Setting a user’s role to No access on a building doesn’t delete their user record. They stay on the account and can be re-permissioned later without a new invitation.

How permission levels combine

A user’s effective role on any given building comes from the most specific level where they have a role set. When the user tries to access a building, Gridium checks the building level first, then the region, then All buildings, and uses whichever role it finds first. More specific settings always override less specific ones.

A few examples:

  • A user has Viewer at the All buildings level and Full user on Building 1. They’re a full user on Building 1 and a viewer everywhere else on the account.
  • A user has Full user on Region A and No access on Building 5 (which is in Region A). They have full user access to every building in Region A except Building 5, where they have no access.
  • A user has nothing set at any level. They have no access to any building on the account.

When you change a role at the All buildings or region level, any explicit roles already set on individual buildings stay in place as exceptions. The higher-level role only fills in for buildings (or regions) that don’t have their own explicit setting.

To override an inherited role for a specific building, set an explicit role on that building. The building-level role takes precedence over the inherited one for that building only; other buildings under the same region or All buildings setting are unaffected.

Regions

A region is a type of building group used for managing user permissions across multiple buildings at once. When you assign a role to someone on a region, that role applies to every building in the region.

Regions are the only type of building group that affects user access. Other types of building groups exist in Gridium for organization and reporting, but they don’t have permission controls.

Regions are most useful for portfolio accounts with many buildings, where managing permissions building by building gets tedious. Common patterns:

  • Use regions to group buildings geographically, with regional engineers assigned full user access to the buildings in their territory.
  • Use regions to group buildings by ownership or management contract, with vendor users assigned access only to the buildings they manage.

If you add a building to a region after a user already has a role on that region, the user automatically picks up the role on the new building. They don’t need to be re-permissioned. If you remove a building from a region, any access the user had through the region is lost on that building, but any explicit role on the building itself remains in place.

To create or edit regions, go to the account settings menu and click the Building groups tab. From there, you can create new regions, rename existing ones, and add or remove buildings from each one. The same tab is also used to manage other types of building groups, but only regions affect user access. Only account admins can edit building groups.

Editing user details

Each user on your account has a profile that includes their name, email, title, and phone number. Account admins can edit any of these fields for any user on the account by opening the user’s profile from the account users page.

Users can also edit their own profile from their personal user settings. They can update their name, title, phone, and password from there.

Email subscriptions

Each user controls their own email subscriptions from their user settings. From there, they can choose which buildings they want to receive notifications about and what kinds of notifications they want (alerts, summaries, reports, and so on).

Removing a user

Account admins can remove a user from the account at any time from the account users page. Removing a user revokes all their access to the account and to every building on it. The user’s underlying Gridium record is preserved, so if they’re also on other accounts, those continue to work normally. If they later get re-invited to your account, their existing record picks back up rather than being created from scratch.

Audit history

Every change to user access, permissions, and account settings is logged. Account admins can review the audit history from the Activity tab in account settings. Each entry shows what changed, when, and who made the change. The history is useful for periodic security reviews and for diagnosing access issues, like figuring out how a particular user ended up with full access to a building they shouldn’t have.