Bizagi projects
This article explains what a project in Bizagi is and presents a list of considerations to help you decide when to automate in a single project or in multiple projects.
You may hear someone referring to a project as a project instance. They both mean the same thing:
Think of a Bizagi project instance as a file. Each file is independent from each other; it has access rights that are defined independently from other files, and teams can work collaboratively on them. A Bizagi project instance,can contain as many processes as needed to accomplish your automation initiative.
Bizagi projects are automated in the development environment using Bizagi Studio. That is where you define your company’s process flows, the data structure, the business rules and all the underlying components of a fully automated process.
Each project requires it own bundle of development-test-production environments. Thus, each project has AT LEAST three environments: the development environment, a testing environment and the production environment.
You can opt to have more environments for your project if your business requires it: for example a Staging environment.
If you are thinking on having multiple Production environments (and thus, develop on multiple project instances) you need to purchase a development and a test environment INDEPENDENT for each project.
The following image shows Bizagi’s infrastructure, presenting how multiple projects are provisioned.
In a single project, multiple developers can work collaboratively, using Bizagi Studio from their workstations and run the development environment's Work Portal using a web browser. Any change made by a developer is reflected in the project's database, and all developers can see changes reflected.
Multiple projects are used to deliver different implementations: when you want to have independent cloud resources for each project, a different set of developers or a different set of end users accessing each production environment.
Since an independent bundle of development-test-production environments is needed, when working with multiple, EACH project requires its own test and production environments.
Depending on your business scenarios, automating in a single project instance or in multiple project instances is equally valid.
Keep in mind that merging information spread in multiple projects is not supported.
Data and metadata shared
oIn a single project all developers share the same project structure (data model), as well as global definitions such as Organization, Security definitions, Library rules, among others. All processes created share the metadata and the data. A single project has separate environments (development, test, and production) with their own URL and database.
oIn multiple projects each one has its own structure. No data nor metadata is shared among them. Development teams are independent, and cloud resources are isolated from one team to another. Each project has separate environments (a development environment and their corresponding test and production), with different URLs and databases segregated by project and by environment.
User management
Bizagi Studio’s authentication for developers is configured independently from the access of end users in the testing or production environments (Work Portal access).
Developers in Studio Cloud Services
Bizagi Studio is the tool used by developers to automate processes. The authentication for all projects relies on the Identity provider configured in the Customer Portal. Learn about Customer Portal authentication..
You can configure multiple identity providers. This is useful when developing under a single project and having developers logging in with different domains. Learn about multiple authentication in Customer Portal.
oIn a single project, there is one development team. Access rights to work in the project in Studio are granted through the Customer Portal.
oIn multiple projects, access rights for each project are independent. If a user has access to one project, they must be granted access to work in another, if required.
End users in the Work Portal
The Work Portal is a web application which lets each user perform their corresponding tasks and configurations. Before working in the application, each user must identify themselves to the system so that only the right people can perform such activities. Learn about Work Portal access.
Each project has its own independent authentication configuration. Furthermore, each environment within the project (dev-test-prod) has its own independent authentication, configured in the Customer Portal.
The Work Portal supports Multiple Authentication, to use several authentication types and domains. This is the common choice in a project with users from more than one domain. For example, if your project is accessed from different locations and each location uses a different a Identity provider. Learn about Multiple authentication.
oMultiple projects: if you need to isolate and separate all access rights for end users to the processes in a project, consider creating multiple projects. Remember that each project has its own URL and authentication configuration.
Administrators in the Work Portal
The Work Portal is managed by end users with specific roles that grant access to the different administration menus.
oWhen working on a Single project containing processes that are managed by people in different departments or even organizations, it is important to consider User management.
User management within the Work Portal is not segregated by departments or organizations. Admin users who access the User management menu will be able to look for and manage ALL end users in the project.
Project administrators in Management Console
The Management Console (MC) is a web-based application that lets you manage live parameters of each environment (dev, test, production), such as integration endpoints and authentication or authorization settings. There is no difference in this portal when having a single or multiple projects.
The following roles in the Customer Portal have access to that MC, independently for each project: Company Administrator, Studio subscription owner, Studio project owner and Studio contributor.
Deployments
oSingle project: all packages deployed to the test or production environments must always come from the same development environment. While deploying, a maintenance window is displayed for some seconds.
oMultiple projects: all packages deployed to the test or production environment must always come from the same development environment. While deploying a maintenance window is displayed for some seconds, exclusively on the target environment, no other environments are affected.
Project management
All projects and their environments (dev-test-prod) are managed through the Customer Portal.
Each project has access rights defined that are independent from the other projects. However, the Company administrators can manage all projects.
When the subscription requires maintenance or if there is a version update for any of the products or projects, all products and projects will be part of the downtime.
Learn about the different roles in Customer Portal.
Running the Work Portal
oSingle project: every time the Work Portal is launched from Studio, the tool performs a small deployment, and the web application will become unavailable for some seconds.
oMultiple projects: running the Work Portal is completely independent from one project to another. The unavailability of the Work Portal only affects the project where the execution happened.
VPN and Disaster Recovery
•The Disaster Recovery Service (DRS) is INDEPENDENT for every Production environment. For example, if a customer has three Production environments, they may purchase one, two or three DRS.
•A single VPN applies for the entire subscription: Studio Cloud Services and Automation Services, including all environments. However, an additional VPN needs to be purchased when acquiring Disaster Recovery Service.
•A same IP Whitelist definition covers all the cloud services, projects, and environments of the subscription.
Considerations to configure security developing in a single project
Bizagi offers a variety of configuration possibilities regarding developer’s access to resources in Bizagi Studio and end user access at run-time (test and production). There are many levels on which you can configure permissions.
Project’s structure |
To achieve greater segregation levels, we suggest breaking down and categorizing processes into different Bizagi Studio Applications. Use Applications when having different teams developing over a single project, and when their processes are independent. However, this implies that there is no re-usability between processes. |
Bizagi Studio security |
Restrict access to Studio resources to prevent developers from modifying something that is not part of their responsibilities. |
Defining performers |
On the fifth step of the Process Wizard, define the performers (end users) of each task by defining the qualities needed to be assigned. Only those users that meet the assignation criteria will have the task available to act. |
Access rights to menus and processes |
Set access rights to elements of the Work Portal. When end users are restricted from an element, they will not be able to see it. The restricted element will only be visible to end users with access rights. These rights are managed through the definition of Security in Studio or Management Console. |
Case security |
You can define access rights for cases in the Work Portal, so users without privileges cannot see any information on a case. |
Last Updated 5/6/2022 5:14:46 PM