In BriefBuilder, you can assign user roles on two levels:
- Environment level: What is a user allowed to do/see in the BriefBuilder environment?
- Project model level: What is a user allowed to do/see in a particular project model?
The roles at project model level can be defined per project model. The environment roles are fixed. Both will be explained below.
Environment roles
On an environment level, there are four fixed roles to choose from:
- Project model user
- Project model creator
- Environment editor
- Environment administrator
Each of these is explained below.
(1) Project model user
This is default role when you add a new user. It is the most suitable role for people who should only have access to specific project models (e.g. architect or engineers of a particular project).
Permissions:
- Access to one or more particular project models
Please note: users with this role cannot see or edit any project model until they have been given a specific project role for that project. See here for how to do that.
(2) Project model creator
This role is used for people who should have access to one or more specific project models AND have the ability to create new project models. It typically concerns project managers who do not need access to all models in an environment, but still need to be able to start up their own new projects.
Permissions:
- Access to one or more particular project models
- Create new project models
- Clone, delete, archive, and restore any project model 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 project models of their colleagues, they can clone these and they can create new project models.
Permissions:
- Create new project models
- Clone project models
- View all project models in the environment (active and archived)
(4) Environment administrator
This role is reserved for the BriefBuilder ‘super users’ in an organisation: the ones that knows most about BriefBuilder and it responsible for the overall user management.
Permissions:
- Same as Environment editor, plus
- Delete project models
- Archive projects models, restore archived project models
- 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.
Once 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 permissions overview, you can see the following functional areas.
- Model (overall settings, i.e. project home, modules, roles, report definitions, table definitions)
- Requirements
- IFC data
- Requirements analysis
- Verification (plan – result -demonstration document – assessment)
- Request for change (request – 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 settings of 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 executor: can enter verification results for verifications that are assigned to them personally or to their organisation or their role.
- Verification assessor: can assess verification outcomes
- Viewer – comments: can make comments only
- Viewer – published versions: cannot edit any data; can only view published versions.
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
- Configure rights for (shared) table definitions
- 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.
(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.
Please note: with the viewer role, users cannot edit anything, but they can export data in various formats so that they can use the data in their own applications, e.g. for the purpose of requirements analysis or design verification.