As environment administrator, you can add users via the user management menu that can be found by clicking on your name, in the upper right corner of the screen.
You have to go through the following steps
Step 1: Create a user account
Create a new user account by clicking on the + symbol
If you have create a lot of user accounts, it may be a good idea to import these via Excel. Read here for how to do that.
Step 2: Fill in the user’s details
Add details for the account that you want to create:
- Name: the person’s name (will, for example, be used in Comment section)
- Email: the person’s email address.
- User name: the name that has to be used for logging into the application.
Please note: the new user account is added as the last one on the list. So, in case of a long list, go to the last page to see the newly added account.
Please note: if users have access to multiple environments, make sure that they have a unique user name for each environment.
Step 3: Select environment role
Define the user’s role on an environment level. In short, you have the following possibilities:
- Project participant (this is the default): can edit or view data of specific projects.
- Environment editor: can create new projects and see all other projects.
- Environment administrator: same as above, but can also do user management.
Click here for a more detailed explanation of the different roles.
Step 4: Select project role
Define the user’s role on a project level. In short, you have the following possibilities:
- Not linked to project (this is the default): cannot see the project (unless your are an environment administrator or environment editor)
- Owner: can edit everything and can publish different versions of the project.
- Editor: can edit requirements, analysis, verification plan, verification outcome, RFC (request), and RFC (assessment), depending on selection.
- Viewer all versions, with comments: can view all project versions and add comments.
- Viewer all versions: can view all project versions.
- Viewer published versions: can only view published versions of the project.
Click here for a more detailed explanation of the different roles.
Step 5: Send invitation
Send the invite to the user by clicking on the mail icon. The e-mail contains the user name, a link for (re)setting a password, and a link to the application.
Some examples
As you understand from the above, there are quite number of possibilities. See below for a couple of practical examples for how you can assign roles, both within a project and within an organization.
Example 1: roles within a simple project
In a simple building project, user roles could be assigned as follows:
| Actor | Need | BriefBuilder Role |
| Project leader | Starts the project and is ‘editor-in-chief’ of the overall set of requirements. Responsible for publishing/access/change management. | Project owner |
| Briefing consultant | Needs to be able to add/edit requirements in the model | Editor-requirements |
| Architect/ engineers | Needs to be able to see all the requirements and should be able to make comments (e.g. asking for clarifications or changes per object) | Viewer with comments |
Example 2: roles within a complex project
In a more complex project, with a rigorous approach to quality control, user roles could be assigned as follows:
| Actor | Need | BriefBuilder Role |
| Requirements manager | Starts the project and is ‘editor-in-chief’ of the overall set of requirements. Responsible for publishing/access/change management. | Project owner |
| Requirement specialist | Needs to be able to add/edit requirements to specific parts of the model | Editor-requirements |
| Verification/quality manager | Needs to be able to develop a verification plan, defining how, when and by whom requirements will be verified | Editor – verification plan |
| Architect/engineer | Needs to be see able to see all the requirements and should be able to analyse and verify requirements. | Editor – analysis + verification |
| External stakeholder (e.g. users) | Needs to be able to see all requirements and should be able to make comments | Viewer with comments |
Example 3: roles within an organisation
In an organisation that uses BriefBuilder for multiple projects (e.g. a professional construction client or an engineering firm), the following roles will be relevant:
| Actor | Need | BriefBuilder Role |
| Consultant/ expert | Needs to be able to start up (or clone) projects, and should be able to see the projects of colleagues (for knowledge sharing). | Environment editor |
| BriefBuilder administrator | Needs to be to be able to see and do everything in the BriefBuilder environment to support the people working with it. | Environment administrator |
| Ad-hoc project collaborator | Does not need to see everything. Will be invited on a project-by-project basis. | Project participant |