Table of permissions
General
On this page, the meaning of different permissions is described.
Permissions define what actions a user can perform on each object.
Permissions are group-specific, meaning they are not granted directly to the user but to the user group.
A user can belong to multiple user groups.
In addition to user groups, a user's permissions depend on the type of license they have obtained.
Examples of license types include Viewer, which allows only retrieving and viewing objects, or Creator, which also allows creating and editing objects.
General information about permissions: Permissions
Levels of permissions
Different user groups may have different levels of permissions for the same object.
If a user belongs to multiple user groups, their permissions are determined by the strongest level of permission.
In addition to this, the creator of an object always has write permissions to the object they created.
Below are the rights listed with their meanings.
Rights are listed from weakest to strongest.
A stronger right includes the weaker one.
Name of the permission | User may | |||||
|---|---|---|---|---|---|---|
Rmeta | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
View | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Read | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
Write | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
All (Admin) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Table of permissions
At its simplest, the permission table is a table where rows represent user groups.
Permission levels are listed as columns from left to right in order of strength.
In the permission table, rights are granted rather than taken away.
By default, a group has no rights: If a user group's name is missing from the permission table, the group has no rights to the object at all.
Multiple permission tables can be associated with an object. You can see them on the object's rights page.
Example:
The permission table in the image shows that administrators have full rights, the sales team has read-only rights, and designers have write rights.
See what kind of permissions people have at least
(1) Select the object.
(2) Choose the action Object > Permissions (where Object could be e.g., Project, Customer, Document, Item, Model, Drawing, etc.).
Flow opens the Permissions dialog: Object, XYZ (where XYZ is the object identifier).
(3) Hover the cursor over the permission. (In the image, the cursor is positioned over the "Read" permission.)
Flow displays a tooltip listing the names of individuals who have at least this permission.
See who belongs to the group that has permissions to the object
(1) Select the object.
(2) Choose the action Object > Permissions.
Flow opens the Permissions dialog: Object, XYZ.
(3) Hover the cursor over the group. (In the image, the cursor is placed over the "Design" word.)
Flow displays a tooltip listing the names of individuals belonging to the group.
An example of model usage permissions
The permissions for model 10040 are defined in the permission rule "Ready (SIS)", meaning model 10040 does not have an individual permission table.
See permission rules: Permission Rules.
The model is allowed hierarchical inherited permissions.
See: Hierarchical Permissions.
In the lowest "Other Permissions" table, it is stated that the creator of the model always has write access to the object, regardless of whether they belong to the System Administrator or Product Development groups.
