Continuous improvement and considerations for incremental Deployments

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Deployment of processes and new versions >

Continuous improvement and considerations for incremental Deployments


As part of continuous Process improvement, Bizagi allows the evolution of your Processes as your business evolves.

Sometimes this involves making changes to business data, business rules, interfaces or even changing the flow of the Process itself.


Depending on the necessary changes, it is recommended to generate new versions of Processes when they have been already deployed to Production.

This is a safe way to make changes without compromising the information of the current cases being executed in the Production environment.


However, publishing minor modifications to existing Processes is also possible, so that the current cases can take those changes and adjustments.

This section describes and guides when it should be recommended to create new versions for existing Processes, and how to handle minor changes when required for an existing Process.



Continuous improvement

Note that changes to a Process that is already in the Production environment, is always performed in the Development environment, and then taken to Production by executing a deployment.


Changes required to be done from the Development environment involve: new workflow Tasks or transitions, forms additions or changes in them, business rules changes, new performers or integration definitions, amongst others.





Management tasks and configurations can be changed too and carried out directly in the Production Work Portal. Such management tasks include: editing business policies, users administration tasks and authorization configuration, or administration for the SMTP server or ECM systems, amongst others.


Keep in mind that it is always recommended to make use of the Test environment to perform deployments of your Processes before deploying them to Production.

This way, you can always check and adjust your Processes so that they cover the expected behavior (as these will be applied in Production).



Incremental deployments

For continuous improvement of your Processes and for deployments to an existing Production environment, take into account the following considerations in your Development environment:



1. Objects in Production must remain in Development

Once a Process is deployed to the Production environment (or is currently marked as Release Candidate in the Test environment), it is not possible to delete any of those objects used by that Process version in the Development environment.


Amongst such objects, these listed are included: entities, attributes and relationships, forms, business rules, performers assignments (assignation rules), systems, and organization definitions.


Similarly, it is not possible to modify the Name property of objects already used in Production (that is, to change their name).

This behavior is restricted in order to guarantee the stability of the Production environment in a subsequent deployment.





2. Versioning Processes

Once a Process is deployed to the Production environment (or is currently marked as Release Candidate in the Test environment), its current Process is locked so that it is not possible to edit the workflow model for that specific version.


As a result the Process' version cannot be edited by using the Process Wizard's step 1 (addition, edition or deletion of shapes or transitions is not possible).


If you wish to make these type of major changes to a workflow model, then you must create a new version of that Process (and its Sub-Processes).





On the other hand, you may choose not to create a new version of the Process if the required changes are somewhat minor:


Adding a new attribute or entity.

Adding or editing current business rules (Action Events, performers assignments, Web or REST services' invocations).

Creating a new query form or entity query.


In other words, a new version is not required if changes can be made through the Process Wizard from steps 2 and later. Detailed edition possibilities for the existing objects worked on through the Process Wizard steps 2 and later is detailed in the next section.



Changes made in the current version (without creating a new one), would apply in the Production environment directly to the existing cases.

Thus, in this scenario it is important that proper tests and cautions are taken into consideration for both new cases and existing ones; in order to avoid consistency errors for the deployed Processes.


View further information about the guidelines and recommendations for a new version of a Process.



3. Edition possibilities for objects in Production

Once a Process is deployed to the Production environment or is currently marked as Release Candidate in the Test environment, Bizagi Studio (the Development environment) will control the edition possibilities for those objects used by that Process version.

This is restricted in order to guarantee the stability of the Production environment in a subsequent deployment.


This means that for a Process version already deployed in Production environment or marked as Release Candidate, it will be usually a best practice to create a new Process version with the new requirements and adjustments (oriented to continuous improvement), if the modifications required are "big changes".


However, you may also choose to make minor changes to Processes (and their objects) which are already in Production (and have the existing cases take those changes).  To edit objects which are already being used in Production, refer to the possible options in the table below:




Entities and Attributes

Entities and attributes (including relationships) will not be editable in their: name, type, or source.

Only their display name can be edited.


Forms may not be edited (adding, modifying or deleting fields, or those fields' expressions, validations or actions will not be possible).

However, forms may be cloned or versioned in a separate way, allowing the possibility to define which form version is the current form for an Activity.

Expressions (Boolean and scripting type)

Its code may be edited (along with its display name or description property).

Proper cautions should be taken into consideration.

Custom Functions

Its code may be edited (along with its description property).


Its code may be edited (along with its description property).

Performers Definition (Assignation Rules)

All properties and definitions are editable for Work allocation (assignment rules of Tasks may be changed).

Organization Definitions

Only the display name of the elements defined for the organization may be edited (e.g., display name for existing Areas, Roles, Skills, User groups).

Holiday Schemas

Only the description of the defined holiday schemas may be edited.

Security settings

Changes for Authentication and LDAP should be done directly in the Production environment through the Management Console.

Changes done in development regarding Authorization settings will always be taken to the Production environment, and overwrite the Production environment's configuration.

Email messages

New messages (using the multiple messages feature) in an e-mail message configuration may be included.

Existing messages in the multiple messages feature cannot be removed.

In a message, its subject, recipient ("To", "CC", and "BCC"), and body content may be edited.

The conditions to send off an e-mail may be edited as well but not deleted.


Its content may be edited.

Interfaces invocations

Web services invocations may be configured again through the interfaces wizard.

Minor changes in an existing interface (those which do not require new mappings) can be done directly in the Production environment through the Management Console.


All its properties may be edited (except its Name).

Component Library


Its registered assembly/jar file can be changed.

Custom Jobs


Only new Job Steps and Schedules may be added to an existing Custom Job.


For any other change required which is not possible for an existing object in Production, creating a new Process version and using a new object will be necessary.



4. New business keys

When defining new business keys, it is recommended to ensure that the data in Production complies with this new restriction. Otherwise, applying the business key in Production will show an error during the deployment procedure (in order to protect your Production environment and ensure its data integrity).

For example, if you have an entity called "Product", do not define that its column ProductName should be a business key if you see that in the Production environment there is more than one Product record which has the same ProductName.  Suppose the ProductName column has multiple instances of the value "Credit" then its values are not unique and so the column cannot be used as a business key.


Click for more information about Predefining business keys.



5. Previous configurations must remain compatible

Do not alter any of the required configurations involved in your previous deployments.


This means that your database instance should not change its collation (applies to SQL Server) or the configured character set (applies to Oracle).


If you need to move your Production server to a different new server, ensure you do so by using the Server management options presented by Bizagi in its Management Console.

Click for more information about Server management through the Management Console.