Overview
Bizagi offers a collaborative environment where you and process developers can work simultaneously on the same project.
If you have several processes in your project you might need to restrict access to some resources to prevent other users modifying one process that will affect other processes.
By default, each new Bizagi project enables users included as Bizagi administrators to access all the project’s objects. Access rights to specific objects of the project are not configured.
We encourage enabling Bizagi Studio Security to make sure the right users have access to managing the correct project resources.
Resources for which security can be managed are:
•Applications
•Processes
•Entities
•Global Business Rules
As soon as a resource has any type of security (either to deny or to allow access), Bizagi will assume that the resource is restricted and only users with Create, Modify or Full Control access will be able to modify it. All others will be prevented from modifying the resource.
Resources with Security
Security can be managed for certain elements, or resources in Bizagi Studio. Security can be assigned to specific users or to an entire user group.
The specific security action varies depending on the type of Resource. There are three actions:
•Create: allows to create a Resource.
•Modify: allows editing a Resource but not creating a new one.
•Full Control: users can execute every possible action on a Resource (Create, Modify, Delete) and assign Security to it.
Access rights are inherited. When you have permission on a Resource with a higher hierarchy, you also have permissions over its child Resources. Unless the child Resource has specific permissions of its own.
The following list describes the Resources and the actions relating to each of them.
Applications and processes security
Resource |
Create |
Modify |
Full Control |
|---|---|---|---|
Applications main node |
Create new applications |
N/A |
N/A |
Applications |
Create new Processes and Sub-Processes |
Is visible and modifiable |
Create, modify and manage Security |
Processes |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
Process versions |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
•Access rights are inherited. If you have Modify permissions over an application, then you will also have permissions over all the process related to that application and all its elements: Forms, business rules, expressions, etc. Everything contained in the hierarchical tree.
•The creation of new processes will inherit the Security configuration given to their related application.
Entities security
Resource |
Create |
Modify |
Full Control |
|---|---|---|---|
Entities main node |
Create new entities |
N/A |
N/A |
Application entities |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
Master entities |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
Parameter entities |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
•Most projects have entities that are crucial for the proper functioning of a process, and any uncontrolled changes can affect its development. You can restrict access permissions to those entities to limit modifications.
•Access rights are inherited. If you have Modify permissions over an entity then you will also have permissions over all its related elements: Attributes, forms, values, queries, expressions. All descendants in the hierarchical data of the given entity.
•When you have been denied the Modify permissions over an entity, you will not be able to modify any of its elements. Note the entity's elements will be available for use (in Forms, expressions) but NOT for modification.
Global Business Rules security
Resource |
Create |
Modify |
Full Control |
|---|---|---|---|
Applications |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
Global Functions |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
Global Expressions |
N/A |
Is visible and modifiable |
Create, modify and manage Security |
•When you have been denied the Modify permissions over an expression or a function, you will not be able to modify it. The expression or function will be available for use but can NOT be modified.
Administrators and non-Administrators
•Only Administrators have the right to add additional users and groups in the Bizagi Studio Security option.
•Administrators will be able to grant rights for all elements that handle security (i.e., Authentication, Authorization and LDAP) in Bizagi Studio.
•Administrators will always have access rights over all elements that handle security in Bizagi Studio.
•Users that are NOT Administrators will not be able to grant rights for elements that handle security in Bizagi Studio, unless they have Full Control permissions over a certain resource.
•Users that are NOT Administrators will be able to create or modify elements that handle security in Bizagi Studio, according to the rights given by Administrators.
Additional considerations
•When you configure Bizagi Studio Security, users and user group lists will be populated automatically with the users that are already part of the project's Bizagi Administrator Group. This group is configured through the server's Management in Windows operating systems.
•When you add users to any element in Bizagi Studio Security they will be included automatically in the Bizagi Administrators Group.
•If you delete any user from Bizagi Studio Security, they will NOT be deleted from the Bizagi Administrators Group.
•When a user has been restricted (denied) to modify an element, but is able to access it (like Forms, or business rules), if attempting to edit they will receive a message:
The same applies to the results of the Search option, which returns all the elements that match a condition. However, if a user does not have permissions over one result's item, a window informs the user of this restriction.