In Bizagi you can set access rights to different elements of the Work Portal's to restrict the end user in modifying or viewing certain information relevant to the project's performance and administration.
When users are restricted from an element, they will not be able to see the element from the Work Portal.
As soon as an element is allocated any restriction (to either deny or allow), Bizagi will assume that the element is restricted.
The restricted element will only be visible to users with access rights to that element.
Access rights to the different elements of the Work Portal are managed through the definition of roles and user groups.
In the Authorization component you can manage access to the following items:
MENU |
DESCRIPTION |
|---|---|
Analysis
|
Allows or denies access to specific Processes' information in the various Process Analysis Tools. If access is denied for a specific Process, you will able to access the Reports menu, but you will not be able to view that Process in the Business Activities Monitoring BAM, Sensors Analytics, Process and Task Analytics and you cannot see it listed in the Wizard drop down list. |
Applications |
Allows or denies access to applications. These permissions are granted for each application individually. If permission is denied for a specific application, then you will not be able to create new cases of any processes that belong to that restricted application; nor will you be able to view cases related to such processes in your Inbox. Be aware that you are still able to be assigned to tasks of a Process that belong to a restricted application, despite not having access rights to the application. For this reason take care when implementing this restriction. |
Entities |
Allows or denies administration privileges for Parameter entities in the Work Portal. These permissions are granted for each entity individually.
The administration privileges that can be set are: •Full Control: Permits total administration of an entity, that is, if allowed, you will be able to create new records of the specified entity as well as view and modify existing entities. •View Data: If allowed, you will be able to view records of the entity only. Changes to data will not be permitted. •Modify: If allowed, you will be able to view and modify the records of the entity, but not to create new records. •Create: If allowed, you will be able to create new records for the entity, but not to modify the existing records. |
Allows or denies the management of Alarms, Asynchronous Work Items, Cases, Default Users and Profiles. |
|
Allows or denies the creation of new cases. These permissions are granted for each process individually.
If permission is denied for a specific Process, you will not be able to create new cases of that Process; however, you may still be assigned to activities belonging to such a restricted process. |
|
Controls access to the menu and submenus pages of the Work Portal. These permissions are granted for each page individually. IMPORTANT: In the Analysis menu, the permissions applied to All Reports cascade down to all sub-menus. This means that if access is denied in All Reports you will not be able to access any of its features or lower level directories (sub-menus). To see all the options that can be configured through this menu, refer to Pages menu options. |
|
Policies |
Allows or denies access to policies. These permissions are granted for each policy individually. If access is denied for a specific policy, the restricted policy will not be visible in the Business Policies menu of the Work Portal; consequently, you will not be able to gain access to it. |
Allows or denies access to case queries. These permissions are granted for each query individually. If access is denied for a specific query, the related form of the restricted query will not be visible in the Queries menu of the Work Portal. |
|
Personas |
Allows or denies administration privileges for Persona entities in the Work Portal. These permissions are granted for each entity individually.
The administration privileges that can be set are: •Full Control: Permits total administration of an entity, that is, if allowed, you will be able to create new records of the specified entity as well as view and modify existing entities. •View Data: If allowed, you will be able to view records of the entity only. Changes to data will not be permitted. •Modify: If allowed, you will be able to view and modify the records of the entity, but not to create new records. •Create: If allowed, you will be able to create new records for the entity, but not to modify the existing records. |
Vocabularies |
Allows or denies administration privileges for global, application, or process vocabularies.
The administration privileges that can be set are: •Full Control: Permits total administration of global, application, or process vocabularies; that is, if allowed, you will be able to create new global or process vocabularies, as well as view and modify existing ones. •View Data: If allowed, you will be able to view global, application, or process only. Changes to them will not be permitted. •Modify: If allowed, you will be able to view and modify global, application, or process vocabularies, but not to create new ones. |
Additional Authorization facts
The following applies to all Authorization modules:
1. When no Authorization is explicitly defined (i.e to start new cases), then by default, all users (all roles and all user groups) will be authorized (i.e, everyone can start new cases).
2. If only one certain role or user group is authorized (explicitly allowed), then other users not contained in this definition, by default will be not be authorized (denied).
The same applies vice versa: when only having one certain role or user group denied, this will result in having the other users not contained in this definition as authorized (allowed).
Should there be definitions of: one role or user group with denied access and another role or user group with allowed access, then other users not contained in this definition will have a denied access (having at least one allow definition will deny access to users not explicitly allowed).
3. When having one role or user group with denied access and another role or user group with allowed access, and should there be a user which belongs to both definitions, then this user will have access denied (un-authorization prevails over authorization in case of ambiguity).
4. If a role or user group is unauthorized to access a case, they may find the case through BAM or using the case link. Nevertheless, a warning message appears informing that the user is not authorized to access the case.
Last Updated 6/9/2023 3:28:52 AM