Why private processes are not good?
I present two important reasons why you should not use private processes within Bizagi:
- Reporting Challenges: One significant problem I have encountered is related to reporting. When cases are marked as private, the information displayed in reports depends on the user running the report. If the user has access to the case, the related information will be included in the report. However, if the user does not have access, the information will be excluded. This can create complications when you have a Manager role specifically designated for reporting purposes only. In such cases, the manager needs to be granted permission to view case details in the reports using commands like “CHelper.GrantCaseAccess(Me.Case.Id, iUserId).” But what happens when a new manager is added to the role? Do you have to run the same command for all the existing cases? While it is technically possible, it would be more convenient if this process was simplified.
- Access Management Challenges: The second issue with private processes is related to the constant changes in personnel who require access to the cases. As roles change or new people are assigned to a particular role, the access to cases should be dynamic. However, when using private processes, manually managing these access changes can become cumbersome. It becomes necessary to constantly update permissions and ensure that the right individuals have access to the appropriate cases. This can be time-consuming and prone to errors.
Considering these challenges, I strongly recommend avoiding the use of private processes in Bizagi. Instead, it is advisable to explore the following alternative approach that offers more efficient and dynamic ways of managing reporting and access permissions within the system.
What should I use instead?
I strongly recommend utilizing visibility rules on the summary form instead. By implementing simple expressions that evaluate whether a user’s role matches certain criteria, you can determine whether they should have access to the summary page. For example, if a user has the role of Manager, you can allow access to the summary page. On the other hand, if the user has a different role that shouldn’t have access to the case, you can restrict their access.
Visibility rules based on user roles are straightforward to manage and modify in the future if needed. If there are changes to the roles or access requirements, you can easily update the expressions without extensive manual adjustments. This flexibility ensures that the access permissions remain aligned with the evolving needs of your organization.
By utilizing visibility rules, you can simplify the process of controlling access to the summary page in Bizagi. It provides a more efficient and dynamic approach compared to using private processes.
