Overview
Bizagi Studio provides a collaborative environment where you and your teammates can work simultaneously on the implementation of processes.
In the teamwork setup, you need to create a project which is considered as the centralized project for all your process developers. This project must be created in a project server, then each developer can access the information of the same project using Bizagi Studio from their workstations. So any change made by a developer affects the same project's database, and all users can see changes reflected.
To accommodate this, Bizagi supports a teamwork collaborative setup for the Development/Authoring environment. Each process developer can open the project using Bizagi Studio, and run the development environment's Work Portal using a web browser.
In the image above, the Project Server is the central server hosting the Bizagi project components. The database can be set separately in a dedicated database server (recommended), though it is possible to set it at your central server as well.
Before You Start
Make sure that you meet the installation requirements. See Teamwork setup system requirements.
Setup
For the setup, you need to configure the Project Server, the database server, and the workstations. For more information about this setup, refer to Teamwork collaboration through Bizagi Studio
Teamwork collaboration features
Bizagi enables coordinated interaction amongst users and presents the following features to empower teamwork collaboration.
1. Applications and categories to group processes (a hierarchical structure)
A Bizagi project may contain as many processes as you need to successfully accomplish your organization's automation initiative.
Bizagi allows you to organize your processes by defining a hierarchical structure in which applications and categories are used to group processes (e.g according to the different business units). For more information, refer to Defining your company's project structure.
2. Bizagi Studio security for access control
When having several processes in your project you might want to restrict access to some of the project definitions (i.e processes), to control which users can modify the implementation of specific processes, in order to prevent unauthorized access or to avoiding affecting in turn other processes depending on those processes. For more information about access control settings for team members working on the same Bizagi project, refer to Bizagi Studio security.
3. Check-in, Check-out controls
Bizagi avoids conflicts in the stored information when users work at the same time on the same process diagram, by using a Check-in and Check-out control.
When a user is editing a process diagram, in the first step of the Process Wizard, it will be checked-out for that user only, and blocked for editing for everyone else. As soon as the user closes the diagram, it will be checked-in and thus, available for everyone else. For more information about this control in the process model definition, refer to the Processes module view.
This same concept applies when users work in the definition of the user interfaces. When creating or editing the forms to be presented to end users, automatic Check-in and Check-out control is provided. For more information about this control in user interfaces, refer to Forms security.
With the above features, we strongly recommend that you establish rules with your development team and communicate with each other, especially when planning to delete objects or to do important changes (i.e in business rules, the data model, or other modules), in order to avoid overwrites or applying changes with are not consequent with others' work.
Multiple projects
With Bizagi Studio, you may have multiple Bizagi projects being hosted on the same server (by using any of the two setup options described above), and work on implementations separately.
Recall that each Bizagi project can contain any number of processes, and multiple projects are not usually needed nor ideal in most cases. Merging information spread in multiple projects is not supported.
Multiple projects should be only needed to deliver different implementations, which is when you do want to have separate databases for each project, a different set of end users accessing each project and possibly using a different type of authentication.
When deploying processes to a production environment (using Automation Server), note that it is recommended to have a dedicated server running one Bizagi project, so that you can have a most accurate sizing for that project, and so that resources consumption or the execution of admin tasks related to the platform of one project do not affect others.
Alternative setup using Remote Desktop Services at the project server
You can rely on host-enabled services such as Remote Desktop services in order to allow workstations to do a remote connection with the project server using the Bizagi Studio Installed in it.
The Bizagi Studio in the project server would be used to open that hosted project and work on it, and use a central IIS for the Work portal (applies to a .NET platform).
This setup is recommended when the network connection between workstations and the project server hosting the project present latency issues (i.e specifically on scenarios having the central server at the cloud). To install Bizagi Studio at the server for this setup, you would need a domain admin account, and to rely on the Terminal Services options for a multi-user setup.
For more information about this setup, refer to Teamwork collaboration through Terminal Services.