Case Security

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition >

Case Security


There are companies in which the management of information is a very sensitive issue that requires special control to limit the data exposure. That is why it is necessary to define the authorization to access information through the Work Portal, indicating which users have permissions over a case and which are unauthorized to see privileged information.


In a scenario without customization of security, anyone can find a case and, in the results table, access all the related information. However, this information may be confidential and would need to be restricted to some users who might see it and study it.


According to the needs of each project there are two types of users that can be defined in Bizagi for a case:

Users without privileges cannot see any information on the case.

Users with privileges can see all the information of a case.


Privileged users will be:

Those who have worked on the case

The creator of the case.

Users who have been assigned. The allocation method Everyone will automatically include all users that can take a case.

Users added through an expression granting them privileges





Case security explained

Security must be defined at the Process level from the Expert View.

Processes can have one of three possible security levels that will be applied to each case created:

Public: Anyone can search and view all the case information.

Private: Only privileged users have access to the case’s information.

As parent Process (applies to Sub-Processes): security will be shared between the parent Process and child Process (or Sub-Process). If the parent Process has Private security all users who have privileges on the parent Process may access the child's information and vice versa. If the parent process has Public security, all cases of parent and child processes can be seen by all users.





Private Case security




As Parent security



Delegated users can see cases that are assigned to them in their Pending list. If they are NOT part of the privileged users they will not be able to search and find the case through the query engine.


Case security scenarios

In the Work Portal it is possible to access cases from several places:


Search by case number  


Pending list


For the first two scenarios, the Case Security will apply. That is, if a user is part of privileged users they will have access to the case’s information accessed by any of these places. The Pending list does not have Case Security. If a user is assigned a case or it has been delegated, the case will always appear in the Pending list and it can be accessed along with all its information.


Security must be defined in the development environment of a project. It cannot be configured in production because security is tied to the lifespan of each case. Therefore, it cannot be included in the middle of an existing case. If you need to alter the case security in the Production environment. First, make the required changes in the development environment and then deploy to Production.



Though you part from having a Case security definition for your project, you may rely on expressions or Bizagi's API for external systems (SOAP web services) to grant or revoke access to specific cases. For more information about these options, refer to:

Manage privileges through expressions

Manage privileges through web services


Important notes

Consider these notes:


1. Business Administrator or Super user

Case Security has a role, called BA Business Administrator,  that can be assigned to any user. A user with this role will be able to consult any case without restrictions. That is, a Business Administrator user will always be regarded as a Privileged user across all processes.


2. Sub-Processes and inherited security

Sub-Processes can be created As Parent security so that users who have privileges on the parent process will retain these privileges for the child process (Sub-Process) and vice versa. In the Purchase Request Process, once the Boss approves the request a new Sub-Process is created, called Quotations.




The person responsible for making quotations, a user called Quotations will be assigned. Since this person is an assigned user he/she will be able to see the Sub-Process information in the Pending list. Furthermore, as this Sub_Process has parent security, he/she will be able to access all the parent’s case information.


1. In the Expert View, select the Properties of the Process.




2. In the properties window, select the As Parent Process case security.



With this security setting, the users assigned to the Sub-Process will also have access to the parent Process information.




3. Sub-Processes not inheriting security

The Sub-Processes that does NOT have As Parent Process security behaves like any other process, Public or Private. If they are Private the users with privileges on the Sub-Process will not have privileges on the parent case. Similarly, privileged users of the parent process will not have privileges on the Sub-Process.


In the Purchase Request Process, once the Boss approves the request, a Quotations Sub-Process is created. The person responsible for making quotations, (a user called Quotations) will be assigned. As a privileged user (assignee) of the Sub-Process, he/she will be able to see its information in the Pending list. Furthermore, in the Pending list, he/she will be able to see the information of the entire case to which this Sub-Process belongs. However, as the Sub-Process DOES NOT have parent security, Quotations user cannot inherit any privileges. In addition, this user has not been assigned (or added) to the parent case (only the Sub-Process).  



Quotations user is NOT part of the privileged users and will NOT be able to search and find the case through the query engine.


4. Stakeholder case security

Unauthorized users will not be able to see the "Work on it" button for Stakeholders cases.


5. Comes into effect

Enabling case security will come into effect for new cases. That is, it is not retroactive, and cases created prior to enabling the case security will not be covered by the feature. For example, 5 cases were created before enabling case security, then after it is enabled the cases created from that point on will count with the considered configurations, nonetheless, those 5 cases created previously will keep on going with the configurations they had enabled at the moment of their creation.