In BriefBuilder, you can assign user roles on two levels:
Environment level: What is a user allowed to do/see within the client environment?
Project model level: What is a user allowed to do/see within a particular project model?
The roles at project model level (project roles) can be defined and managed at the level of the individual projects. The environment roles are fixed. Both will be explained below.
On an environment level, there are three roles to choose from:
This is default role when you add a new user. This role is typically assigned to people who should only have access to one or more specific projects. It typically concerns external parties (e.g. architect or engineers of a specific project).
|Access to one or more particular projects|
This role is typically assigned to people working within the client organisation who work with BriefBuilder on a regular basis. They can see the projects of their colleagues and can clone/create new projects for themselves.
|Create new projects|
|View all projects in the environment (active and archived)|
This role is reserved for the BriefBuilder ‘super user’ within the organisation: the one that knows most about BriefBuilder, does user management, and helps his or her colleagues in the use of BriefBuilder.
|Same as Environment editor, plus|
|Archive projects, restore archived projects|
|View and restore back-ups|
On a project model level, you can define your own roles.
This is particularly useful when multiple users should have the same set of permissions.
The definition of project roles takes place in the settings menu of your project model. To get there, do the following
- Open the Navigation menu (on the left side of your screen)
- Go to Settings (bottom of the menu)
- Go to Project Model
- Click on Roles
Adding new roles
In the role menu, you can find a set of default roles, but you can also easily add new roles.
This can be done clicking on the button, which can be found right next to the table’s header. (‘Roles’)
The default permissions for a newly added role include only viewing rights (for all versions of your model).
Other permissions (i.e. permissions to configure the set-up, edit data or make comments) can be added by clicking on the icons in the permissions overview. These are the following:
|Configure||allows users to configure the model set-up via the settings menu|
|Edit||allows users to edit data|
|Comment||allows users to make comments|
These permissions have to be defined per functional part of the model:
|Model settings (concerning modules, roles and user access).|
|Project home page|
NB You may have noticed that not all permissions are relevant to all model parts. This relates to how the application is build up. There is, for example, no comment permission for RFC assessments because all comments are linked to the RFC requests.
Access to versions
In the permissions table’s first column you can also define to which model versions a role gives access.
As explained here, we distinguish between published versions and other versions. Publishes versions are the formally published, ‘frozen’ versions of a model. This means—by definition—that if you choose published versions only for a role, that role cannot be associated with any edit rights.
You can easily delete roles by clicking on the bin icon at the end of the row.
Please note: if a role is linked to one or more users, you will get a warning notification because your action is likely to impact what these users can do in the model.
In the default set-up of BriefBuilder, you are provided with the following roles:
- Requirements manager: can edit basically everything (maximum rights).
- Requirements modeller: can edit requirements
- Requirements reviewer: can make a requirements analysis
- Verification manager: can develop a verification plan
- Verification editor: can enter verification results
- Viewer – comments: can make comments only
- Viewer – published versions: cannot edit any data and only view published versions (minimum rights).
But, as said, this is just the default set-up which can easily be changed. The only two fixed roles (which cannot be deleted or changed) are:
This is a role with maximum permissions. It is typically assigned to the person who is responsible for the model set-up and the overall requirements management process.
Viewer – published versions
This is a role with minimum permissions. You cannot edit anything and only view the formally published versions of the project model.
For a detailed overview the permissions for all the default project roles click on the image below.