All Collections
Rights and Users
Falcon's permission system explained in detail
Falcon's permission system explained in detail

Learn how Falcon handles permissions and get to know the basic difference between unguarded and guarded tree items

Jonas Steeger avatar
Written by Jonas Steeger
Updated over a week ago

These two resources will surely be helpful to you as cheat sheets when assigning permissions:

Falcon makes it possible for you to adapt the permission structure specifically to your project. In the following article we explain in detail how this works. Here you will find everything in one go!

Unguarded vs. Guarded

Falcon distinguishes between public and guarded tree elements. 

Unguarded: All Falcon users can describe and change content. All have the permission to write.

Guarded: Hub owners and admins determine the permission individually. Users who have assigned responsibilities (e.g. in the profile or for activities) are given write permission for guarded elements.

Attention! Settings in the profile are inherited! Users who have been defined as responsible in the profile have write permission in guarded tree elements. This permission is inherited downwards. If, for example, you have defined a user as responsible on the profile in a measure package, the user can write in all measures of the package. If you want to be sure that the permission have been assigned as desired, you can view the tool from the perspective of any user. More information here.

You can determine whether something is public or guarded via the permissions tab. The selected setting is inherited downwards through the tree - as you may already know it from Freeze. If you move a guarded activity in an unguarded package, the protection remains intact. If you move an unguarded activity into a guarded package, the activity is automatically guarded.

What do users see in the tree?

Falcon has numerous options to set permissions. It is possible to define which tree elements are visible to whom. 

But regardless of the settings made, a user with an authorization sees at least the measure name, the measure package name and the project name in the tree. 

Permissions, group permissions, special permissions, roles, participations and participations

User permissions:

Attention! In guarded elements, a responsibility (e.g. for activity) automatically leads to a write permission, but can be overwritten by a set permission on the same tree element. For example, the read permission of a user in an measure overwrites the write permission obtained in the same measure due to an activity.

  1. Write: Allows users to describe and modify content. Excluded are contents that are reserved for administrators.

  2. Read: Allows users to read content only.

  3. Manage: Allows users to manage content and thus grants them admin permissions at project, package or measure level. Thus, users with admin permissions can check off status reports, describe the plan and partially delete content (depending on specific manage level). A write user can also check off status reports.

If you want to guard a tree element, you have to define individually which user should read and write in the permissions tab in the admin center. The assigned permission remain stored when you make the tree element unguarded again and are reactivated when the element is guarded.

Special permissions:

  1. Hub owners: You manage the entire Falcon hub and thus all projects equally. Whether unguarded or guarded, hub owners can always create and delete projects as well as users. 

  2. Invisible: If you select Invisible for a user instead of Read or Write, the user is deprived of any permissions, provided the user has no responsibilities in the area. Invisible is therefore a kind of negative permission.

  

Group permissions:

  • Falcon also allows you to create and manage groups and group permissions for guarded tree elements. You can see how this works here.

Roles:

  1. Hub owner: You manage the entire Falcon hub and thus all projects equally. Whether unguarded or guarded, hub owners are always allowed to create and delete projects.

  2. Admins: They are created project-specifically by the hub owners. Whether unguarded or guarded, admins are allowed to do everything in their respective projects, packages or measures.

  3. User: The permissions of the users are individually regulated by hub owners and project administrators.

Involvement and membership

Attention! A user is already involved with an activity or a write permission and gets insight into the dashboard - and that is already the most important thing for you. Nevertheless, we would like to explain to you below which vocabulary we use for Falcon.

Through involvement and memberships Falcon regulates in particular which representations are available to the user in the dashboard. Falcon distinguishes between involvement and membership. Involved persons are always operationally connected to a project. Members can also take on a purely observational role. Falcon distinguishes four involvements:

  1. Involved in the project: All users who have at least one responsibility in the project.

  2. Measure package involved: All users who have at least one responsibility in a measure package.

  3. Measure involved: All users who have at least one responsibility in a measure.

  4. Activity involved: All users who are responsible for an activity.

Project members are practically all users who are responsible for something or who hold a permission. Falcon distinguishes between three types of memberships:

  1. Project members: All users with at least one reading permission in the entire project.

  2. Measure package members: All users with at least one reading permission in a measure or a package.

  3. Measure members: All users who have at least one reading permission in a measure.

Note: Check the user permission individually - with just one click: In the user administration and in the permissions tab, you can right-click on a particular user to check their "permissions" and thus view Falcon from the user's perspective, so to speak. This provides security when assigning permissions.

Did this answer your question?