General information

Tutorials and guides for the features of Octaved Flow

Project folders and permission roles

In Octaved Flow, projects can be organized in project folders. The top level is the company or organization and is named as you specified when activating the Octaved Flow demo. For example My company GmbH.
The project folders below Meine Firma GmbH can, for example, be departments or business units of Meine Firma GmbH. It would also be possible to create a folder for each customer or for specific customer groups. The principle is completely flexible.
The idea for project folders is similar to a file system ("drive"), where there are folders and files. Folders correspond to project folders, files to projects. Just as a system administrator typically assigns permissions for folders - and not for individual files - in Windows, permissions are assigned for project folders in Octaved Flow. It is best to set up the structure of the project folders in such a way that permissions can be administered conveniently and with minimal subsequent maintenance effort.
It is perfectly legitimate to dispense with project folders and only have all projects at the top level My company GmbH. All permissions are then administered at this level. If you have no idea how to organize your projects in project folders, then just leave it as it is. You can also do it later and then reorganize your projects. Then simply work with the only project folder that exists, the Meine Firma GmbH folder.
Users receive rights to a project folder by being assigned an permission role for this project folder. This applies to both users and groups of users.
Depending on the license level, project folders may or may not be visible to you. In the basic license, you only have one superordinate level in which you can organize your projects and assign permission roles.
The permission roles are:
  • Reader - Users with this permission role can see everything in the projects, but cannot edit anything.
  • Standard - Users with this permission role can do everything they need to do to complete work packages. This includes, for example, marking work packages as completed, creating and checking off tasks, writing board posts and booking times in projects. The Standard permission role cannot be used to perform actions that are reserved for project managers and department heads. It is not possible to create and delete projects and work packages, view prices, edit commercial details such as maximum effort, assign responsible persons, plan work packages and change their planning.
  • Full - The Full permission role contains all permissions for projects, sub-projects and work packages. It is usually assigned to project managers, department heads and managing directors.
  • None - This permission role cancels an inherited permission role. Users with this permission role have no access.
 Permission roles
As you can see, the permission roles are in ascending order from None to Full.
The permissions are additive, or in other words "higher sticks". If someone has the Standard permission role for a project folder as a member of a group and the Full permission role as an individual user, then Full wins. In case of doubt, the higher permission role always wins.
Briefly summarized once again: On a project folder, a user (or a group of users) is assigned one of the permission roles None, Reader, Standard or Full.
This setting then applies to all projects in the project folder and controls the user's rights for the folder and all contained projects.
In a project, the permission role that a user has received via project folders cannot be reduced or removed in a project.

Rights upgrade

And there is another useful effect: there is a connection between project roles and permission roles. This is best illustrated using an example. Let's assume that a user in the project folder has the Reader permission role. They therefore only have the right to read all projects and work packages. If a work package is now assigned to this user as an executor, they would not have sufficient rights to actually be able to work on this work package. For example, the user would not be able to write anything on the board, book any times or mark the work package as completed.
Of course, you could give the user the Standard permission role for precisely this work package, which would make all this possible. But wouldn't that be far too much administrative effort? That's why Octaved Flow has an automatic "upgrade" of permission roles instead. If a user has a project role as an executor, they automatically receive an upgrade to the Standard permission role for this work package.
The context is as follows: With a project role of type Executor, one receives an upgrade to the permission role Standard. With a project role of the type Project manager you get an upgrade to the permission role Full. For the upgrade it doesn't matter which permission role the user had before. And it doesn't matter what project role designations are common in your company or organization. Anyone with too few permissions to perform the assigned project role simply gets an upgrade.
Permissions with project roles

Good to know

If you have the None permission role on the project folder, it is not possible to access the work package. The reason is obvious: if you can't even see the project folder, you can't get any further. So if you give a user the None permission role for a project folder, you should be sure that the user will have nothing to do with these projects. Incidentally, this procedure is helpful if you want to set up a client system because, for example, there are two independent business units in your company. But back to the actual topic!
In summary, you only need to do the following: If necessary, create project roles according to your requirements and assign a corresponding permission role to each project role.Then all you have to do is assign users with their respective project role to the work package and Octaved Flow will do the rest automatically.

Best practice for project roles and permission roles

The points described in this section are only an initial guide and are intended to provide a better understanding.
Project managers are usually assigned the Full permission role at folder level. This is necessary so that they can create projects at all. This is also useful so that a project manager can stand in for a project manager colleague on vacation or sick leave without having to make any adjustments to the permission system.
Executors receive either the Reader or Standard permission role on project folders. Executors then receive a role of the project role type Executor for the respective work package.
A sub-project manager can receive a project role of the type Project manager for a group (of work packages) and thus manage a part of the project.

Project roles and permission roles in summary comparison

Permission roles determine what a user is allowed to do.
Project roles define which function or role you have in the project.The project role shows responsibility to the outside world. If others see that I have the project manager project role for a project, they know that they can contact me if they have any questions about this project.
The situation where a user has the responsibility for a project but not the permission to fulfill the responsibility is solved in Octaved Flow via the permission upgrade. If you have less permission than responsibility, you automatically receive the appropriate upgrade.

Menu item Permissions

In the settings under More is the menu item Permissions. Permissions are set here that apply either globally or to the system settings themselves.
The logic here is that users are added to the roles and thus receive the corresponding permission.
Permissions on system settings
The global administrator has unlimited rights in Octaved Flow. This includes all menu items under Settings, the ability to manage permissions for project folders and to read and edit all project details. In very small organizations, where otherwise all users are allowed to do everything, all users can be global administrators. For this purpose, the group All internal users is added here, in which all internal users are always automatically included. This is the default setting when you register for Octaved Flow, i.e. when you create an Octaved Flow for your own organization.
In medium-sized and larger organizations, the global administrators are probably employees of the IT department. To do this, the group All internal users is removed and the corresponding users are added. The users can be added directly or as a group. As you cannot revoke the global administrator right yourself, you must first add yourself before you can remove the All internal users group.
It is recommended that at least two users are global administrators.
The Administrator for system settings can use most of the menu items under Settings. The following restrictions apply:
  • he cannot use the Permissions menu item (otherwise he could make himself a global administrator).
  • he can create and edit project folders in the Project folders menu item, but cannot manage the permissions for project folders.
  • he cannot manage users, neither internal nor guest users.
  • the menu items LDAP and Webhooks are only available for on-premise installations of Octaved Flow. Note: In the cloud version, these two menu items are not available to anyone.
In contrast to the global administrator, the Administrator for system settings does not have global access to all projects.
If the role of global administrator is performed by employees from the IT department, department heads from specialist departments, central project management or Octaved Flow key users, for example, can be Administrator for system settings.
There are other roles in the table. The explanation for each entry is displayed in the help.
Under Permissions, you can also define who can see whose time bookings.

See time booking list

If you do not use Octaved Flow's project time booking, you can skip this section.
Project time booking is a sensitive issue in many companies and organizations. When it comes to others being able to see what you have done during the day, it crosses a red line for some.
In Octaved Flow, everyone can decide for themselves who is allowed to see their own time bookings and also take away this possibility from someone else. This can also be defined centrally by the administrator via the menu item Permissions in the system settings.
Ultimately, it is about a matrix of all users, in which it is specified who may see whose time bookings. What are the effects of being allowed or not allowed to see the time bookings of others?
The setting that user A is not allowed to see B's time entries has two effects. First, user A sees B's time bookings only anonymously in the context of work packages. A can see all time bookings for a work package and that makes sense. Because the activity descriptions in the time booking can be very helpful, for example when one takes over a work package or continues to work on it. Also, you might want to copy time entries so that it is more consistent to the customer. But A doesn't see B's name in the time booking.
As a user, if I don't have at least the Reader permission role for a work package, I can't see time entries for that work package in any case, anywhere in Octaved Flow. What permissions do I need as a user to see time postings?
I am allowed to see a time booking anonymously if:
  • I have at least the Reader permission role for the work package.
I am additionally allowed to see the name of the person who made the booking, if:
  • I have at least the permission role Full for the work package, so I am usually the project manager of the project - or
  • In the system settings under permissions it has been set that everyone is allowed to see the time bookings of everyone - or
  • The other user has given me the right to see his time bookings via the time booking matrix or the administrator has configured it this way in the system settings.
Whoever has the permission role Full for a project, i.e. is a project manager, can always see all time bookings in the project by name, in order to be able to clarify any questions or discrepancies.
In Octaved Flow there is a list of all time bookings per day. Here you can add team colleagues. In the described case, however, A cannot add B to this overview, not even anonymously.
By default, Octaved Flow is set to allow everyone to see everyone's time bookings.

Groups of users

Users can be grouped into user groups. A user can be in any number of groups.
The idea of groups is to save clicks. If you want to add the same users in multiple places to set permissions, it is worth creating a group for those users. Then instead of adding multiple users, you only need to add one group.
Groups at project folder permissions
Groups can also be used in meeting time postings. You can mention a group in a post in the board to mention all members of the group about the post. Again, the group saves clicks.
dot background image