Bizagi offers a variety of configuration possibilities regarding user access to information and there are many levels on which you can configure those permissions. This document serves a high level summary of those alternatives.
Take into account that all this features are available and apply for users that have been authenticated. Non authenticated users are not able to access the Work Portal and thus they do not have access to any information. For more details about authentication, refer to Work Portal Access.
From a general standpoint, sorted from highest to lowest configuration level, you can tailor your information access control by:
Configuring your information access control
As mentioned in the previous section of the article, there are many levels at which you can configure the information your users have access to. In the development of this section, you can find additional information and resources about each of the security alternatives Bizagi has to offer.
Within the authoring environment (in Bizagi Studio) On the fifth step of the Process Wizard, Bizagi allows you to define the performers of each of the tasks of a process. By relying on this feature, you can define what are the qualities a user needs to match to be assigned to a task. This way, only those users that meet the assignation criteria will have a specific task available to take action. For the users that don't meet the requirements, this will act as a Read-only mode, since they will be able to find and review the case without being assigned to it, leaving them disabled to take action.
By defining preconditions, assignation methods, and allocation rules you can customize the way Bizagi assigns tasks to different users. You can use the user roles (or any other attribute) to specify that a task can only be performed by a user of a certain position, or even define your own expression to assign a task.
For further details on how to set up your performers and all the possibilities regarding assignation, refer to Performers
This possibility lets you configure which profiles or roles of end users can see which processes and menu options in Bizagi's Web Application (referred to as "Bizagi Work Portal").
There are plenty of individual options to configure, and they are all available to be tailored to your needs under the Authorization node of the Management Console Web. This lets you edit and control the authorization any time without needing to deploy. Refer to Security Option.
The Authorization options lets you modify the user access permissions to many different categories of your application. For instance, if you want to restrict the access of the administration of Parameter Entities managed in production to your users, you can do so in the Entities category. Or if you want to control the users who can start new cases of a specific set of processes, you can do so in the New Cases category.
These options can also be configured from Bizagi Studio, and deployed to all your environments.
For additional information on what each of the categories lets you configure and what permission possibilities they have to offer, refer to Grant Access Rights.
This configuration alternative lets you define whether users that are not involved with a Process instance (a case) can find the case, review it and access all its related information, even when a case is already closed. Restricting this access is known as setting Case Security as Private.
This is useful for those cases when the management of information is a very sensitive issue and requires special control to limit the data exposure. If you set the Case Security as private for a specific process, only users with privileges can see all the case's information.
Users who match at least one of the following criteria are considered privileged:
•Users who have worked on the case.
•The case creator.
•Users who have been assigned to the case.
•Users that have been added through an expression.
Any other users will not find the case, and thus they cannot access its information or details.
This is configured individually for each process within the authoring environment (in Bizagi Studio) by navigating to its properties in the Expert view.
For additional information about setting up Case Security, refer to Case Security.
If you would rather define which information is available to your users depending on the point of execution of a case or on the role of the user reviewing the case, instead of hiding or showing the case altogether to a specific set of users, you can do so by customizing the user interfaces.
The forms builder lets you set whether a control is visible, editable, or required dynamically, by using expressions. This means that you can write an expression on which if a condition is met the control changes its behavior; letting you hide the information to a specific role, or making a field required if a specific user is working on that task of the case.
This is a less strict configuration than preventing a user from actually finding a case, but it also gives you more granular control over what a user is able to do and review.
For a detailed and practical guide on how to configure such expressions, refer to Editable, Visible, or Required.
Even though the previous possibilities enable most of our users to set up their information access control according to their needs, Bizagi offers another possibility in case there are other scenarios that are not natively considered.
If you want to offer a different user experience from what Bizagi offers with its forms builder and also configure a different way to show or hide sensitive information, you can rely on constructing your own Widgets. With them you may define and build your own elements and controls to address more sophisticated scenarios. With this option you may even integrate a sign-pad or even implement a UI control that masks information according to the type of user.
For additional information on how to build custom widgets and how this may help you meet your information access control standards, refer to Widgets.
By setting up Business Keys for your entities, you are effectively setting a code-based structure so that information stored in tables relies on unique codes (known as "Business keys"). This is helpful in complying with standards, for example in the health sector, and it also allows for best practices in terms of integration with other systems and managing information in general, since it avoids duplicate values and other inconvenient situations when storing data.
For additional information about the benefits of using Business Keys and how to configure them in Bizagi, refer to Business Keys.
Any work session using the Work Portal starts with the user logging into the application. Only authenticated users can effectively enter the Work Portal to start reviewing information and taking action on cases. That is why it is very important to configure an Authentication method that meets your standards. The following diagram depicts how authentication works from a general standpoint.
Bizagi offers a variety of alternatives to configure Authentication on your applications. By default Bizagi will handle Authentication itself, storing the usernames and passwords on the same Database that your registers are stored, even though all this information is adequately encrypted, it is a good practice to store the Authentication information independently from the Business related information. Bizagi offers many integration alternatives regarding Authentication so that you can use a method that satisfies your needs.
For detailed information on authentication, its alternatives, benefits and guides on how to configure it, refer to Environment Identity and Access Management.
Take into account that Bizagi offers these configurations that must be leveraged by the customer. The information access control and security is ensured by the customer when implementing their processes, by making sure that adequate access rights are set to menu options in the Work Portal, performers are correctly configured according to your needs, using Case Security, defining roles for participants, modeling user interfaces that only display appropriate information, configuring Business keys and attributes encryption, and by Integrating the Authentication alternative of your choice.
Bizagi is not responsible for unwanted access to information or security breaches since it all depends on the configurations made by the customer before making the application available to the end users.