Sharing processes between projects

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Bizagi Studio user interface explained > Advanced settings > Export / Import >

Sharing processes between projects


During process automation, you may find yourself in a situation where you need to share your processes with other Studio users. Bizagi helps you share your processes along with their business rules, parametric values, forms and other settings, with the options available in the Import/Export menu, in your development environment.


Export/Import menu with all the avaiable options: Deploy process, microdeployment, share processes and import from process modeler, import process and import from the Process Xchange



What you need to do

To share your processes, you need to follow these steps.

1.Export the processes in a .btex file.

2.Import the .btex file contents to your project.


Exporting processes to share

Once your process are ready to share, head to the Export/Import menu and select the Share Processes option.


Bizagi Studio with the menu Export/Import and the Share process option highlighted


A window appears where you can select the processes and their versions you want to share.


Export wizard with a list of the available processes for export


In the Experience tab, you can select the experience components you want to include in the the .btex file.




To add an optional description, click Description and type in a brief description for the shared package.


Export process description field


Select the processes you want to share.


Export window with a process selected and the Export button highlighted


Then, if the selected processes have experience components, select them in the Experience tab to include them in the file.




Once finished, click Export to generate the .btex file. If you selected the add password option AddPassword, a window will appear asking for the password to be assigned to the package, it must comply with the mentioned conditions.

When a package with a password is generated, it is encrypted.




Select a name and location for the generated file.




When the export finishes, a window appears showing that the procedure was successful.


Export finished successfully window


You can check the contents of the exported package by clicking View Package. Another window appears where you can navigate the contents.


Window with a list of all the exported contents

To finish, close all the windows.

You can now share your processes through the .btex file you've just created.


Importing the shared processes

When you receive the shared package file, head to the Export/Import menu and select the Processes option under the Import category.


Bizagi Studio with the menu Export/Import and the import process option highlighted


A window appears with the import wizard. Click the Browse button to navigate to the shared .btex file.


Import widow


Select the package you want to import and click Open.




If the .btex file was generated with a password, a window will appear requesting it.




With this, all the process information is displayed on the window.




You can view the objects you are importing by clicking View process object to import. A window appears with all the objects inside the file.




Additionally, you can view the package description when you click View description. A window appears with the package's description.




After you've checked the package's information, click Apply package to import it. Once Bizagi is done importing, a message appears informing so.




To finish, close all windows.

After this, the shared processes are part of your project.



Important Considerations

We strongly recommend that you select the Enable metadata validations option when you import a shared process. This validation detects two of the most common errors that occur during an import:

oReferences to objects that don't exist in the catalog: When an imported object has a reference to an object that doesn't exist in the package or in the target database this validation is triggered.

oProcesses without an associated version: When objects like rules or experience elements don't have an associated process version, this validation error is triggered. If this happens, you must review your export configuration and make sure you selected an associated version for these objects.

These validations are important because they reduce errors substantially.




You can export processes in the following scenarios: within the same Bizagi Studio version or from a lower to a higher version. It is not possible to export processes from a higher to a lower version.


What is exported: all process objects used in the exported package:

oThe Applications of the process chosen and all of its components such as forms, all entities and its components, business rules, vocabularies, component Library, Document Templates (including configuration & uploaded documents), Assemblies, Providers, External Systems, Connectors, Widgets and Custom columns.

oThe package will also contain Organization related information used in the processes chosen: user properties, user groups, Areas, Roles, Skills, Locations, Positions, Work Calendar, Holidays  schema

oWhen you export a parameter entity, it will include its attributes and values.


What is not exported: global objects and configuration information.

oThe package exported does not contain case information (data). It shares metadata.

o it does not contain Environment configuration (including Custom parameters, even if they are used in business rules), Business configuration, Authentication configuration, LDAP configuration, OAuth2 Server Application, Themes, Web Pages (Cases Monitor, Search, Process Admin, Licenses, Stakeholder Admin, Graphic Query, Analysis Queries, BAM, Entity Admin), Custom Jobs, Studio security definition, Sites Metadata, Live processes definition nor Automatic notifications customizations.



Collision scenarios that stop the import

Keeping data consistency is one of Bizagi's main priorities.

Before we proceed it is important to clarify a term: GUID. A GUID is an acronyom that stands for Globally Unique Identifier. Bizagi uses GUIDs internally for every single object, to identify them uniquely from the rest.


There might be cases when importing a process generates a collision. Collisions are packages that cannot be imported for one of the following scenarios:


1. An imported process presents data inconsistency. Possible scenarios that trigger this effect, include, but are not limited to:

oExperience objects that start a process that is missing in the target project.

oMissing attributes in forms.

oRules referencing attributes not included in the package or target project (you can import Rules with replicated names).


2. Processes with different GUIDs and the same names

For example: Project 1 and Project 2 are created independently with a process with the same name. Let's say Vacations. When exporting a package  from Project 1 it will generate collision when imported into Project 2. Thus, it will not be imported.


3. Entities with different GUIDs and the same name.

For example: Project 1 and Project 2 are created independently with an entity with the same name. Let’s say the entity is called Customer. When exporting a package that includes the entity Customer from Project 1, it will generate collision when imported into Project 2.


4. Facts (relationships) and attributes with different GUIDs, with the same name and the same parent object.

For example: We have a Base project and Project derived from it (it can be a backup for example). They will both have the entity Customer. In this case both projects have the entity with the same GUID (unique identifier), and the same name. Two developers, one in each project create a new attribute with the same name on the Customer entity, let’s say Address. When exporting a package from the derived Project and taking it to the Base project it will generate a collision.


When metadata in the target project is kept unchanged

When there are entities, facts and attributes with the same GUID, what is contained in the package imported is ignored and what is in the target project is kept.


When there is a Parameter entity that is managed in development, that is present in both source and target project, and in the target project there are new records of such entity, importing the entity will not remove these new values. This is an important note as is differs from the regular deployment process.


For example: We have a Base project and a project derived it (it can be a backup for example). Let us say that the description of the Country entity was modified in the derived Project and a package was exported to be imported in the Base project. When importing it, the description of the target project will be maintained.


When the metadata in the target project is replaced

1. As with a deployment, existing objects in the target project are replaced with the imported package objects. This applies for:

Rules, Library rules

Component libraries

Connectors y widgets

Default devices

Working time schema and holidays

Forms, Widgets and their localization

User properties


External systems


Experience objects (Entity action, Stakeholder, Trigger, Indirect collection, Searches, Relevant, Default filter, Entity constructor, Context, Categories)


2. When you import the same process more than once, your latest import will create a new process version.


3. Deleted objects: if an object is deleted in the source project, it will be deleted in the target project if the import process finds the same GUID.


4. New facts and attributes of an existing entity in the destination are added.


5. For duplicate Roles, Skills, Locations, Positions, and User Groups

If the GUID is the same in both projects, the objects will be replaced

If the GUID is different, they are added regardless of the name. There will be two objects with the same name (but they will have different GUIDs)