Overview
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, or interfaces, or even changing the flow of the Process itself.
Depending on the necessary changes, we recommend that you 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 advantage of those changes and adjustments.
This section describes when it is best to create new versions for existing processes, and how to handle minor changes when required for an existing process.
Continuous improvement
Note that you always make changes in the Development environment to a process that is already in the Production environment, and then move the changes to Production, once they are satisfactory by executing a deployment.
Changes you must do in the Development environment include: new workflow Tasks or transitions, form additions or changes to existing forms, business rules changes, and new performers or integration definitions.
You can carry out changes to management tasks and configurations directly in the Production Work Portal. Such management tasks include: editing business policies, users administration tasks and authorization configuration, and administration for the SMTP server or ECM systems.
We recommend that you always make use of the Test environment to deploy and test your updated processes before deploying them to Production.
This way, you can check and adjust your processes so that they perform as you need them to.
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 a Release Candidate in the Test environment), do not delete any objects used by that process version in the Development environment.
This covers: entities, attributes and relationships, forms, business rules, performer assignments (assignment rules), systems, and organization definitions.
Similarly, it is not possible to modify the Name property of objects already used in Production.
This behavior is restricted to guarantee the stability of the Production environment in a subsequent deployment.
2. Synchronizing data from another environment
It is a common and recommended practice to create users and use cases in your authoring environment. If you have done so, and the information you have used in the development environment is real data that you need to have in your target environment, the easiest way to transfer that information without having to create it once again is to perform a Data Synchronization. In such procedure, you can handpick which data elements to export into a .bdex file which can then be imported into your target environment.
The data elements that can be considered are Parameter entities managed in production, and Users with their associations.
3. Versioning processes
Once a process is deployed to the Production environment (or is currently marked as Release Candidate in the Test environment), its current version is locked so that it is not possible to edit the workflow model for that specific version.
The process' version cannot be edited using the process Wizard's step 1 (addition, edition or deletion of shapes or transitions is not possible).
If you wish to make this type of major changes to a workflow model, create a new version of the 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 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.
A new version is not required if changes can be made through the process Wizard from steps 2 and later. Editing possibilities for existing objects using process Wizard steps 2 and later are detailed in the next section.
|
Changes made in the current version (without creating a new one), would apply in the Production environment to existing cases. Thus it is important to carry out proper tests and proceed cautiously for both new cases and existing ones; to avoid consistency errors for the deployed processes. |
View further information about the guidelines and recommendations for a new version of a process.
4. Editing options 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) limits the editing possibilities for the 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 a Production environment or marked as a Release Candidate, the best practice is to create a new process version to address new requirements and adjustments (oriented to continuous improvement), if the modifications required are "big changes".
However, you can 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:
OBJECT |
OPTIONS |
|---|---|
Entities and Attributes |
Entities and attributes (including relationships) are not editable in their: name, type, or source. Only their display name can be edited. |
Forms (All types) |
Forms cannot be edited (adding, modifying or deleting fields, or those fields' expressions, validations or actions is not possible). However, forms can be cloned or versioned, and you can define which form version is the current form for an Activity. |
Expressions (Boolean and scripting type) |
The code may be edited (along with the display name or description property). Proper cautions should be taken as you are dealing with "live code". |
Custom Functions |
The code and description property can be edited. |
Widgets |
The code and description property can be edited. |
Performer Definitions (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 can be edited (e.g., display name for existing Areas, Roles, Skills, User groups). |
Holiday Schemas |
Only the description of the defined holiday schemas can be edited. |
Security settings |
Changes for Authentication and LDAP should be done directly in the Production environment through the Management Console. |
Email messages |
New messages (using the multiple messages feature) in an e-mail message configuration can 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 can be edited. The conditions to send an e-mail can be edited but not deleted. |
Document templates |
The content can be edited. |
Interface invocations |
Web services invocations can be reconfigured 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. |
Dimensions |
All properties except the Name can be edited. |
Component Library
|
The registered assembly/jar file can be changed. |
Custom Jobs
|
Only new Job Steps and Schedules can be added to an existing Custom Job. |
Policies |
The description, the display name and the documentation can be edited. |
Connectors |
Minor versions and minor updates can be performed. For more information, refer to versioning connectors. |
For any other change which is not possible for an existing object in Production, creating a new process version and using a new object will be necessary.
5. New business keys
When defining new business keys, make sure that the data in Production complies with the new restriction. Otherwise, applying the business key in Production will throw an error during the deployment procedure (to protect your Production environment and make sure its data integrity).
For example, if you have an entity called "Product", do not define that its column ProductName as a business key if you see that in the Production environment there is more than one Product record which has the same ProductName. If, for instance, the ProductName column has multiple instances of the value "Credit" its values are not unique. The column cannot be used as a business key.
Furthermore, it is not supported to perform changes in the business keys with undeployed attributes. That is t say, if your entity has two attributes defined as the business key and you need to add more, the extra attributes must be deployed before the definition of the new business key.
Click for more information about Predefining business keys.
Last Updated 1/26/2023 3:40:52 PM