7.x Documentation

features description for

Permissions allows you to manage user permissions in multi-user mode in the following ways:

  • based on the rights concept in Microsoft SQL Server
  • with Windows-board resources (e.g. rights of a user in the domain)
    The network administrator can provide each Windows user or the entire Windows user group in your LAN with access rights. The user does not need then to enter any username or password at login, but only choose a database.
  • over different license activations by Named User Clients
  • via authorization management


The native permissions management

Permissions Management

  1. To manage user permissions with, the authorization management must be selected first:
  2. Management of permissions is divided into 3 sections:

    1. Permissions for users
    2. Permissions for Sets
    3. Permissions for extensions
  3. Permissions can also be directly managed for database elements via the properties window, under the tab “Permissions”.

For the granting and managing of permissions, a user with administrative rights (= a user who has been assigned a role with administrator rights), calls the above functions. This member can then manage the access rights for users and user groups within the units for which he has this administration authorization.

The administration area always consists of three areas:

  • The list of users and user groups.
  • The list of roles with the related permissions (administration, design, delete, update, approve, etc.).
  • The unit structure with the display of the activated access rights to units, classes, properties and property groups for the user currently selected. 
    In this third window, only the result of the authorization granting is displayed and nothing can be edited.
When you open the Permissions window for the first time, an automatic update process is started and a progress bar appears at the bottom. This process does not block the work and can also be canceled. During this upgrade process, the Active Directory is checked and the user is updated accordingly.

Permissions for users

Users are managed in according to roles that have different permissions for one or more unitsclassesproperty groups etc. A native, or a Windows user (or a Windows user group), which was created and added to, receives automatically the permissions for all roles to which s/he belongs.

To assign users or user groups one or more roles, or to remove one or more roles, proceed as follows:

  1. Click the user or user group name.
  2. Left-click and check or uncheck the relevant roles.

The user “Admin” and the role of “administrator” are firmly connected with all access rights; no changes are possible here.

If multiple users are simultaneously logged into a database, the administrator can track them: these users are marked in the Administration window in bold.

Owners of elements

All elements (= classes and their objects, diagrams, design elements, users and user groups, as well as sets) belong to an owner in the database. Owners of elements always have the rights to read, update (change), and delete regarding their elements. This means that even if a user has no rights for a unit, but within this unit are objects that s/he owns, s/he can view this unit (with “his/her” elements). 

Manage Users and Roles

To add or remove users or roles or manage their properties, choose the respective button in the toolbar of the administration window, or open the context menu by right-clicking in the corresponding window for users or user groups. You can change the password or create a new one by selecting the password function in the user’s context menu.

In the characteristics of the user, you can also enter details of the users, which may facilitate the identification of the user or the query of their login/logout status. In situations where the access rights of users have to be locked for the units (e.g. in a database design change), you can inform the users on time, as they can be easily identified on the basis of the information entered in the characteristics.

To create a user with his Windows user account, select the respective toolbar button or “Adding a Windows User” from the context menu. You can assign a role to a  Windows user, just like to any other user, edit it there and remove it. If for example the username, description, or other data from the Windows user have been changed in Active Directory, you can update this data for the corresponding Windows user in Click on the “Update” button under the Permissions tab.

You can also add multiple Windows users that belong to a Windows user group at a single time. Select the corresponding icon or the "Adding a Windows user group" from the context menu. You can assign a role to the entire Windows user group as a single user, edit it and remove it.

It is possible to convert native users to Windows users and Windows users to users. Right-click on the user and select “Convert to a Windows user” or “Convert to a user”. Since release 5.3.1 it is possible to create users and roles by copying or cutting either from one database to another, or even within the same database. If you want for Example to add more users or roles that are very similar and subsequently need to be only minimally adapted, it is useful to use the to copy/paste function for users and roles:

  • The connection between the user and the role is maintained, as long as you copy the user within or to a database, where the linked role also exists.
  • The connection between the user and the role is lost - even within the same database, when you copy or cut and paste the role again. All properties of the pasted role are maintained.

Permissions for roles

To manage the permissions of roles:

  1. Click with the left mouse button on the desired role in the Administration window,
  2. Set in the right window the respective permissions in the desired units. You can set the status of a column (e.g. Administration or Design) via the context menu too (right-click on the icon).


The authorization status

If the authorization status is inherited (grey background in the box), this means that settings are taken from the parent field (= from the fields for the parent unit or from the top row of the permissions for a role).

When the authorization status in the parent field is changed, it changes automatically in the inherited child field. The non-inherited permissions status remain unchanged. The status “not activated” (white box) is explicitly used to disable permission within an inheritance structure.


Manage all permissions of a unit

It is also possible to activate or deactivate all permissions for a unit, class, property group or property at one time. Right-click on the desired unit and select the appropriate option from the context menu:

  • Enable All - all permissions for the selected item will be enabled
  • Disable All - all permissions for the selected item will be disabled.
  • Remove all - all permissions for the selected item will be reset (the inherited permissions from the top are moved).

Permissions for system classes, property groups, and properties cannot be set by the user. They are automatically granted to all users who have permissions for the respective unit. Please note that permissions set for Parent Units, are inherited by child units and their classes. If you disable permissions for a Child unit, they are disabled only for the classes created in this unit, but not for classes inherited from the top.


Manage permissions


The Admin user is included in each database, its password is empty at the beginning. The user Admin and the user group administrator cannot be modified or deleted.

The administration authorization can only be granted for Units. If it has been activated for a unit, then a user with this role can manage user permissions as well as the authorization tab in the properties of an object in the unit granted for the Administration. The users with an individual user role with administrative permission can perform the following tasks:

  • Read / Update (Change) / delete / create users and user roles, which they own.
  • Change permissions of user roles for units, for which you have administrative permissions.
  • Change the class of objects and diagrams in the unit in which you have administrative permissions.

The users with an individual user role with Administration authorization cannot perform all operations: there are tasks that can be performed only by the user with the system user role “administrator”:

  • Database-wide management of user permissions.
  • Calling the database settings.
  • Call up the wizard for setting the default language of the model under the database settings.
  • Create new version of the database and start the Version Delta Report.
  • Unlock units, objects and diagrams that have been locked by another user.
  • Remove protection off the diagrams, without entering a password.
Only user with Administration permission is able to change class of object, diagram or file.

The design permissions can only be granted for Units and allows a user role to have access to all design works for the unit(s) in Database Designer.

Design works include creating / updating (changing) / deleting or managing unitsclassesproperties and property groupslink types and link technologies in the class matrix,tags and validation scripts.

When a user has the design permissions on a unit, s/he can create / update / delete in all child units, even if s/he has not been assigned directly permissions to the child units. However, classes, property groups, properties, link types, cross data and validation scripts cannot be created/updated/deleted in the child units. If the design authorization is activated, the update, delete, read and read approved permissions are activated automatically.


The Create authorization can be activated for units and classes and allows a user role to create new repository data in a unit (objects and diagrams) or in a class (only objects). When a user has no rights for a class or a unit, s/he cannot create objects neither in the repository nor in the Little repository of Graphical Visio Modeler. Taking a shape on the diagram, in this case, results in an error message. The authorization for a class can be activated in one Unit and deactivated in a superordinate/subordinate unit. In this case, objects of a class can be created only in a particular unit. If create permissions are granted, the respective user role automatically receives the read and read approved permissions.


The Update permission can be enabled for all elements of the database and allows a user role to change repository items of a unit (objects, diagrams), a class (objects), as well as property values (that appear in the repository). It also allows to link objects with other objects. The linking between two objects requires that the user has update permission for at least one object (or its class). If the Update permission is granted, the user role automatically receives the read and read approved permission.


The Delete permission can be activated for units, classes, objects and diagrams and allows a user role to delete objects or diagrams on the structural level, on which the right was granted. When the delete authorization has been defined, the user role receives automatically the reading and read approved permission.


The Read permission can be enabled for all elements of the database and allows the user role to view the contents of objects and diagrams as well as the property values of the relevant unit or Class in the repository.

  • If a user does not have Read permission on a unit, this unit is not visible to him with all classes, objects and diagrams in the repository, as well as the designer. If this unit however has child units, for which the user has authorization rights, the unit is displayed in the hierarchy tree with the mark “no authorization”.
  • If a user does not have Read permissions for a class, all objects of that class in the repository are invisible (however, the class itself remains visible in the repository and designer).
  • If a user does not have read rights for a property group and the associated properties, the property group itself is displayed as read-only in the Object Properties, under the mark [protected]. Property values are also marked as [protected].
  • When a user does not have read rights for an object or diagram, then the object or diagram is invisible in the Repository. However, if a diagram has some child-diagrams for which the user is authorized, the diagram is displayed in the diagram tree as “no authorization”. The properties of this diagram can be opened, but the property values are invisible to the user.
  • Through this permission, it is possible to open both the class and the link matrix as read-only.

If the Reading permission is generally defined for a user role, it is granted those rights automatically for all subordinate units; but this can be selectively deactivated again. The Read permission is set automatically when the Create, Update or Delete permission has been granted. The Read permission on a unit cannot be removed when the create, update, or delete permissions have been granted for the unit. When the Read permission is defined, the user group is automatically granted the read approved permission. 

Warning: The user role can only see a unit and its subordinates in the repository, if it is not locked.

Read Approved

Read approved is a minimum permission, which allows you to see objects and diagrams with their approval status set to “approved” or with a blank status. The read approved permissions also allow the class matrix and the link matrix to be opened as read-only. The read approved authorization is set automatically when the administration, create, update, delete or read permission has been set.


The permission to approve may only be granted for a whole unit. Only users with permission to approve can approve changes. In addition, the update, reading and read approved permissions are automatically assigned through the approve permission. If a user does not have permission to approve and saves changes to an approved object or diagram, a dialog will open to change the approval status, but cancelling is not possible

  • the user must therefore select an option and confirm their selection.

 ### Permissions for extensions

Permissions can be assigned separately also for the use of the extension modules. This can e.g. be necessary in order to grant or deny certain users the use of individual extensions by concurrent licensing.

The access rights for extensions can be granted only for the entire database and not for individual units. Only users who are members of a user role, to which the appropriate permissions have been assigned, can call and use the respective extension modules.


The authorization for the versioning of a model can be managed here. However, here too the authorization can only be granted for the entire database and not for individual units.

See also: Version Management


Permissions for extensios