Considering applications design

<< Click to Display Table of Contents >>

Navigation:  From Studio to PaaS >

Considering applications design


The first step when deploying business applications to Bizagi PaaS, as described at From Studio to PaaS, is to design, build and automate your processes.

Process automation is how you can convert your process flows into technological applications, while relying on Bizagi Studio.

Before doing so, it is important to ensure that how you use Bizagi's features to automate those processes of your applications, so that these are aligned with your expectations for a production environment.




Rapid prototyping, early validations, and unit tests

Note that Bizagi Studio integrates a runtime Work portal within the development environment, which allows you do rapid prototyping of the UI, or overall tests on the behavior of the business applications, while implementing them.

As this building/implementation stages takes place, the runtime Work portal will reflect all of the changes performed directly in Bizagi Studio in real time, and just as end users in a production environment would see them.




Once verifications in the development environment are completed, you may plan your deployment to the testing environment in Bizagi PaaS.


Designing business applications with Bizagi

Before you publish business application to a testing or a production environment, ensure you completely acknowledge the following concepts associated with working with Bizagi.

Some of these concepts are:


1. Bizagi projects

With Bizagi Studio, you create business applications inside of a Bizagi project.

Within that project, you may create any number of processes (unlimited), while having them share a common data model if desirable (e.g, relying on a same entity definition for customers), share a common set of end users and share a common authentication mechanism, a common URL for end user access, among others. A project will make use of its three default environments (development, testing and production).


Even though through the Studio you may create multiple projects, these are not often needed/ideal and mainly valuable when wanting to deliver different implementations targeted for different setups (e.g, for an on-premises setup).

Deployments to PaaS environments consider business applications stored in one project only, and merging processes spread throughout different projects is not supported.

Notice that within a project, you may design separately a hierarchy for your processes belonging to the different business units, while relying on ACLs for each.


Defining project structure4


To learn more about how to define your company's processes architecture, refer to


2. Organizational elements definition

With Bizagi Studio, you define elements in your organization (such as areas, positions, skills, roles, user groups, etc), that will be involved in processes, either for workload allocation (participants assigned to tasks in the processes) or in order to configure access rights for menu options and processes visibility.

Defining such elements is done directly in the development environment and taken into live environments (i.e, testing or production) via the deployment, though end users are managed directly in live environments so that their areas, positions, skills, roles, or others are configured at any time.

User groups can be edited in the testing or production environments, where you can particularly include or remove users, however for Bizagi PaaS, it is not be possible to create new user groups or delete existing ones.




To learn more about organizational elements definitions with Bizagi, refer to


3. Types of entities in Bizagi

When designing your data model, acknowledge that Bizagi offers 5 types of entities, each having a different treatment in runtime.

Among the 5 types, there is one you will need to fully understand and pay attention the most, in order to leverage best practices for your business applications' maintainability and performance.

The key entity type to consider using according to your business requirement is the one referred to as parameter entities.

These entities allow you to define a list of values you can either: deploy always from your development environment (e.g., a preset status such as Approved or Rejected), or choose to manage directly in your live environments (i.e, to dynamically modify values, such as in a list of cities or offices).




To learn more about parameter entities and their option to be manageable in production environments, refer to


4. Business keys for entities

A Business key is the column or set of columns that uniquely identifies each row in an entity.

Through definitions of business keys, you guarantee that the information held in the key column (or columns) of each record will differentiate it from all the other records in the same entity (avoid duplicates).

Bizagi will not allow inserting a new row that has a same business key value than that one of an existing row.




Consider if you will be relying on such definitions for your entities.

Though it is a recommended practice to explicitly define business keys (especially for parameter entities), note that not every entity necessarily is benefited when using them.

If you will be defining business keys for your entities, consider that may not change this definition for an entity after such entity has been deployed to a production environment.

To learn more about setting business keys in Bizagi, refer to


5. Integration with external systems

Bizagi offers a powerful integration layer that supports the different integration possibilities involved in an enterprise-class, digital transformation initiative.

Through different features you may easily connect Bizagi with Identity Managers, Service-oriented systems offering web services, Document management systems or Enterprise content managers, Email servers or other general applications and cloud services.

For your integration points, It is very important that you rely on the use of A synchronous activities and its properties whenever possible.




To learn more about Asynchronous activities, refer to


For Bizagi PaaS, connecting to certain other applications such as legacy systems, or point-to-point integration with databases, or similar repositories such as Active Directory for users will imply the need for a VPN setup (or in general any corporate system which is hosted on-premises).

Therefore and in this case, you should plan adequately and consider validating and testing how well integration points behave in terms of performance.

This is so given that a VPN will not address any external issues caused by a high latency in the communications between the cloud and your company's servers physical location.



Consider the following aspects to ensure that your implementation is eligible for a deployment to Bizagi PaaS (your processes comply to Bizagi PaaS requirements):

1. You may not run processes in Bizagi PaaS which were downloaded from the Bizagi Process Xchange.

2. You may not run processes in Bizagi PaaS if your project is using Oracle as the database engine.

3. Even though certain features are configured with Bizagi Studio, not all of them will necessarily be taken into Bizagi PaaS as per the defined configuration.

For example, features like the Bizagi database encryption, make sense for on-premises setups and therefore such configuration is not targeted for nor taken to Bizagi PaaS, given that Bizagi PaaS, already manages encryption for data at rest within its cloud-centric architecture.



In addition to the above, it is strongly recommended to ensure that you are using a Bizagi Studio whose major and minor version is the same as the Bizagi Engine version of your Bizagi PaaS environments.

The update and build number may be different though, even so, it is recommended that such update + build number is the same one or lower that the one of your Bizagi PaaS environments.

For example, it is encouraged to use a Bizagi Studio with version and deploy to the cloud to a version



What should I do next?

Once you have grasped the above concepts and recommendations, and have finished implementing your processes, proceed to prepare these processes so you can deploy them to Bizagi PaaS.

For information about this next step, refer to Prepare processes to be exported.