In BriefBuilder, you can assign user roles on two levels:
- Environment level: What is a user allowed to do/see within the environment?
- Project model level: What is a user allowed to do/see within a particular project model?
The roles at project model level can be defined, modified and managed at the level of the individual project models. The environment roles are fixed. Both will be explained below.
Environment roles
On an environment level, there are four fixed roles to choose from:
(1) Project model user
This is default role when you add a new user. This is the most suitable role for people who should only have access to one or more specific projects. It typically concerns external parties (e.g. architect or engineers of a particular project).
Permissions:
- Access to one or more particular projects
Please note: this user cannot see or edit any project until they have been given a specific role for that project. See here for how to do that.
(2) Project model creator
This role is used for people who should only have access to one or more specific projects AND have the ability to create new projects. It typically concerns project managers who do not need access to all project models in an environment, but still need to be able to start up their own new projects.
Permissions:
- Access to one or more particular projects
- Create new projects
- Clone, delete, archive, and restore any project that they have created themselves
(3) Environment editor
This role is typically assigned to people working within the user organisation who work with BriefBuilder on a regular basis. They can see the projects of their colleagues, they can clone these and they can create new projects.
Permissions:
- Create new projects
- Clone projects
- View all projects in the environment (active and archived)
(4) Environment administrator
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.
Permissions:
- Same as Environment editor, plus
- Delete projects
- Archive projects, restore archived projects
- View and restore back-ups
- User management
Project model roles
On a project model level, you can define your own roles. This is particularly useful when multiple users (e.g. all those that have to do verifications) should have the same set of permissions.
The defining 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 (‘Active roles’).
After you have created a new role, you can start defining what that role’s permissions should be.
In this, the first step is define which versions the role should have access to. The second step is to define the edit rights per functional area of the application (requirements, analysis, verification …).
Both steps are explained below.
Note: the default permissions for newly added roles include only viewing rights (for all versions of your model).
Step 1: Defining version access
In the first column of the permissions overview, you can define whether a role should have access to all the project model’s versions or only the published versions.
As explained here, we distinguish between published versions and other versions. Published 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.
If you choose All versions, this will include the working version, which means that you can define what edit rights a role should contain (e.g. only edit rights for verification, for comments, etc).
Step 2: Defining permissions per functional area
In the other columns of the overview, you can see the following functional areas.
| Model (overall settings) | |
| Requirements | |
| Requirements analysis | |
| Verification plan | |
| Verification result | |
| Demonstration document | |
| RFC Request | |
| RFC Assessment |
For each of these, you can define different edit permissions. You do so by clicking on the icons that you see. If an icon is blue, the permission is active. If grey, not.
For most functional areas, the following options are available:
| Configure | allows users to configure the that part of the model, via the settings menu |
| Edit | allows users to edit data in that part of the model |
| Edit assigned objects | allows users to ONLY edit data in that part of the model that is specifically assigned to them (at the moment only available for verification result) |
| Comment | allows users to make comments in that part of the model |
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.
The functional area Model is a bit different from the others because it allows for permissions of a different kind of nature.
| Configure | allows users to activate modules, manage user access and define roles |
| Edit project home | allows users to edit the project home |
| Edit report definitions | allows users to define standard reports |
Deleting roles
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.
Default roles
In the default set-up of BriefBuilder, you are provided with the following project model 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 ALL verification results
- Verification executor: can enter verification results assigned ONLY assigned to them / their organisation / their role
- Viewer – comments: can make comments only
- Viewer – published versions: cannot edit any data; can only view published versions; can make exports/predefined reports.
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 Requirements manager and Viewer – published versions. See below.
Fixed roles
There are two fixed roles in BriefBuilder that cannot be altered: one with maximum permissions and one with minimal permissions.
(1) Requirements manager
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.
Permissions:
- Configure rights for all settings
- Configure rights for (Word) reports
- Edit rights for all requirements
- Edit right for all verification data
- User management on a project level
When creating a new project model as a user, you automatically get this role, as it is your model, so to speak, and should thus be able to control the entire set-up.
(2) 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.
Because viewers (e.g. tenderers such as architects or contractors) may want to work with requirements data, they can make their own reports and exports from the requirements data, which they then can use in their own work processes.