Importing processes

<< Click to Display Table of Contents >>

Navigation:  From Studio to PaaS >

Importing processes


The following section is step number 4 to accomplish a process deployment, as described at From Studio to PaaS.

In this step, a deployment package is applied into a target environment (e.g, testing or production).


Before you start

Before carrying out the procedures involved in this step, it is very important to consider these aspects:

Applying a deployment package is a task that needs to be properly planned, coordinated, scheduled and communicated. It implies planned downtime for the service.

Bizagi PaaS environments are expected to be already created, even though these may not be been actively in use (i.e., testing, production).



In case you have not created a project, follow the steps as described at Create a new project in Bizagi PaaS, while considering if you are using a Personal, or an Enterprise subscription.


Required profile

The person in charge of this step should have authorized access to Bizagi PaaS environments' administration.

Recall that this person does NOT need to be technically skilled in the sense that no programming is needed, and no IT-related tasks are involved in process deployments given that all steps are done via a self-service UI oriented to the business.


Note that the Import processes option is available at the online Management portal available for your Bizagi PaaS subscription.

Therefore, such person will need:

To have at hand, the deployment package (.bex file) as produced in the previous deployment step.

Internet connectivity and a browser to access the Management portal at (as well as credentials with authorized access).

Note that such person does NOT need access to Bizagi Studio (the development environment).


What you need to do

In a summary, applying a deployment package is done by:

1.Accessing the Management portal and locating your target environment.

2.Temporarily stopping your Bizagi PaaS service for the target environment (for Enterprise subscriptions).

3.Uploading and applying the deployment package.

4.Verifying the log and a successful deployment.

5.Starting up your Bizagi PaaS service for that target environment (for Enterprise subscriptions).

6.Verifying your processes and service.



Follow the steps as detailed below.


1. Accessing the Management portal and locating your target environment.

1.1. Open a browser (Chrome is preferred) and go into where you will need to authenticate.
Enter your authorized credentials and click Login when done:





1.2. Go into your subscription by clicking on it:





1.3. Locate the Run category and click on Go to project board:




1.4. Locate your target environment.

Make sure you explicitly double-check that you should be deploying into such environment.




Note that testing environments are identified by the Import_testing icon.

While production environments are identified by the Import_production icon.


2. Temporarily stopping your Bizagi PaaS service for the target environment (available in Enterprise subscriptions).

2.1. Stop your chosen environment's service by clicking the Window maintenance option.

Note that this is required for a successful deployment, and recall that it is always recommended to schedule and perform deployments at non-busy hours, while announcing a maintenance time frame in which there will be planned downtime driven by the business.




2.2. Enabling the Maintenance window option, will result in temporarily stopping the service so that applying processes is successful in that environment.

Ensure you are aware of this, and explicitly tick the Yes, I am sure I want to enable Maintenance check box and click Enable maintenance:




Planned downtime will start from this moment, while it may take up a minute or two to stop your environment's service:




Once this is completed, notice you will see the Maintenance window icon become highlighted, meaning that it is enabled and services are currently stopped:




An active environment whose service is up and running will represent its Maintenance window with the Import_WindowDisabled icon.

While an environment whose service is stopped will represent its Maintenance window with the Import_WindowEnabled icon.

During an enabled Maintenance window, end users will see the following screen when accessing the Work portal:





3. Uploading and applying the deployment package.

3.1. Click the Import process option to upload the deployment package:




3.2. Select the .bex file representing the deployment package.

Notice that the name given to the file has no impact, however you should make sure that you are completely certain that you are uploading the adequate file.




3.3. Double-check and explicitly confirm this action by clicking Confirm, if you own an Enterprise subscription you can View the package's content:




Uploading and applying the package results in importing processes, while it may take up a few minutes:




Once this is completed, notice you will be notified with an Environment ready message displayed at the top right corner:




Notice you should also see the latest applied deployment package appear right under the environment's name.

Even though the package has been imported, it is very important you make sure that overall changes (imported processes, new process versions, etc) behave as expected in your target environment.

You may rely on logs for this, while also having the possibility to rollback a deployed package so that your environment is restored to its immediate previous state, as described next.



Rolling back a deployed package is available for non-production environments.

This means that you may use such option for a testing environment, or a staging environment (if you are using one).


4. Verifying logs and a successful deployment.

4.1. Click o the latest applied deployment package to view the history of applied packages per environment:






Traceability features allow you to click on each row if you have applied more than one deployment package.

For each one, you will see the Deployment log:




The following features are considered by the Deployment log:

A log for each package, regardless of a success or failure in its application.

The full list of logs regarding deployment history is sorted out by presenting the most recent package at the top of the list.

The log details the name of the package, and a timestamp of its application (date), along with the user having done so.

The latest applied package will present a DeploymentLogIcon icon allowing you to rollback that package and restore the environment to its previous state (not available for a production environment and only available for Enterprise subscriptions).

The possibility of downloading any previously applied package by clicking on that specific row.


4.2. If you want to review the log but also the deployment package you applied, you may download it.





Should the download does not start automatically, then you may want to ensure that is authorized to display pop ups in your browser settings:




This way you could open the deployment package with Bizagi Studio in case you want to explore the objects it contains.

Otherwise, you may move on to the next step.


5. Starting up your Bizagi PaaS service for that target environment (available in Enterprise subscriptions).

5.1. Start your service up again by clicking the Window maintenance option, which should be in a highlighted state.

This action disables the Maintenance window:




5.2. Ensure you are aware that disabling the Maintenance window will make the service available to end users, and explicitly tick the Yes, I am sure I want to disable Maintenance window check box and click Disable maintenance:




This action takes up a few minutes:




Once this is completed, notice you will see the Window maintenance option change back to its disabled state (its icon not highlighted).






6. Verifying your processes and service.

6.1. You may then click on Run to review that your Bizagi service is up and running:




6.2. Once you have reviewed that your deployment was completely successful, via Bizagi confirmation messages, logs, and your own tests, then you will be done.

If this is so, you may communicate and announce that your new processes and versions are available to end users.


On the other hand, if you detect that something is not behaving as expected, or if you realize that your imported deployment package did not contain the adequate changes, then you may rollback such changes (available in Enterprise subscriptions).

When deciding to rollback these changes, click on the latest applied deployment package and its Restore to previous state icon:




When restoring to a previous state, consider these aspects:

Applies if you deployed to a testing or stating environment.

You may not restore to a previous state more than once (only rolling back the latest deployed package and no others after it).

This option is presented for 30 calendar days parting from the moment a package was imported.

It will not be available for deployed packages older than 30 days.


6.3. Ensure you are aware that restoring to a previous state will undo the importing of processes and changes included by the latest package, and explicitly tick the Yes, I am sure I want to restore the previous state check box and click Restore package:




This action takes up a few minutes, and after its completion, you are still encouraged to verify that processes in its previous state are now behaving as expected:




What should I do next?

At this point you are done with a process deployment with Bizagi.

Though there is no next step, it is recommended to review and acknowledge considerations for incremental deployments in the future.

For more information about this topic, refer to Continuous improvement and incremental deployments .