Roles and permissions – BDI Cloud

Access in BDI Cloud is granted at a specific level, and a role only means something once you know which level it was assigned at. Being an editor is not a property of your account — it is a property of your account on one particular team, project, or dashboard.

The levels

Level	Grants access to
Team	The team, and the projects belonging to it.
Project	One project and its contents.
Dashboard	One dashboard.
Alert	One alert.

Each level has its own admin, editor, and viewer roles. The same person can hold different roles at different levels, and frequently does.

What each role can do

Role	Can	Cannot
Admin	Full access within its level, including managing members and sharing	Reach into levels above it
Editor	Create and update the things it has access to; delete only what it created itself	Manage users; delete anything created by someone else
Viewer	See the things it has been added to	Change anything

Note: Editors cannot delete work created by other people, but they can delete their own. If a dashboard needs protecting from the person who built it, that is a matter of who holds editor at that level.

Neither editors nor viewers can manage users at any level. User management belongs to admins alone, which is why a project editor cannot grant access to themselves or anyone else.

Access does not flow downward

This is the rule that accounts for most access confusion, and it is worth reading twice.

Editor and viewer access does not inherit into the levels below it. Editing rights on a project do not make you an editor of the dashboards or alerts inside that project. Those are separate grants, made per dashboard and per alert. If you can open a dashboard but every control is unavailable, this is almost always why.

Admin behaves differently, and differently again depending on the level:

A team admin has admin access to the projects belonging to that team, without needing to be added to each one individually.
A project admin has admin access to that one project only. It does not extend to the team, and it does not extend to other projects in the same team.

Two behaviours worth knowing about

A team admin appears on the member list of every project belonging to their team, marked as holding inherited access. Their role cannot be changed or removed from project settings, because it comes from the team rather than from the project. Changing it means changing their team role.

Team membership itself is not currently managed from within the application. Adding people to a team, or changing their role on it, is handled by BDI Cloud Support. Project membership, dashboard sharing, and alert sharing are all managed in-product by an admin at the relevant level.

Choosing what to grant

Start from what someone needs to do rather than from a role name.

Someone who reads dashboards and responds to alerts needs viewer on the project and viewer on the specific dashboards and alerts they use. Someone building and maintaining dashboards needs editor at the dashboard level, not just the project level. Someone responsible for a site's configuration and its members needs project admin.

Grant at the narrowest level that covers the need. Access is easier to widen later than to explain after the fact.