Important considerations when sharing processes

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:

  • References 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.
  • Processes 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:

  • The 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.
  • The 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.
  • When you export a parameter entity, it will include its attributes and values.

• What is not exported: global objects and configuration information.

  • The package exported does not contain case information (data). It shares metadata.
  • 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, 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 acronym 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:

   • Experience objects that start a process that is missing in the target project.
   • Missing attributes in forms.
   • Rules 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 a 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 it differs from the regular deployment process.

For example: We have a Base project and a project derived from 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 and widgets
   • Default devices
   • Working time schema and holidays
   • Forms, Widgets and their localization
   • User properties
   • Authorizations
   • External systems
   • Localizations
   • 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. The following image explains a scenario of sharing the same process.

   

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).