Workflow Version Management

Overview

Enterprise Service Management (ESM) Workflows can be helpful in executing business processes; however, every time a workflow is assigned to a ticket a copy of the workflow is associated to the ticket. This means that as workflows evolve over time to address changes in business process, or fix issues/bugs, it may be necessary to update open tickets with the revised version of the workflow. In ticketing applications with a large number of open tickets at any given time, releasing revised workflows and updating open tickets with the new workflow can quickly become a nightmare.

As a solution to this challenge, we recommend a naming convention that includes a succinct descriptive name (e.g. Software Request) of the workflow followed by a semantic version number (e.g. 2.0.0). A semantic version number, in its simplest form, is a number comprised of three parts broken up into a major, minor, and patch number. These parts can be otherwise interpreted as follows:

• Major - Indicates when major changes, or additions have been made
• Minor - Indicates when minor new functionality is added
• Patch - Indicates when bug fixes are made that do not fundamentally change the existing workflow

Under this scheme, the version numbers, and the way they change convey meaning about the underlying workflow and what has been modified from one version to the next.

A normal version number must take the form of X.Y.Z where X, Y, and Z are non-negative integers, and must not contain leading zeros. X is the major version, Y is the minor version, and Z is the patch version. Each element must increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. A major version of zero (e.g. 0.y.z) is for initial development and workflows of this version should not be used for production use as anything may change at any time. Workflows with a version of 1.0.0 indicates the first version ready for production use.

Incrementing Version Number

• Patch version Z (x.y.Z where x > 0) must be incremented when only backward compatible bug fixes are made that does not fundamentally change the overall business process.
• Minor version Y (x.Y.z where x > 0) must be incremented when minor new backward compatible functionality is added. The patch level must be reset to 0 when minor version is incremented (e.g. 1.8.2 -> 1.9.0)
• Major version X (X.y.z where x > 0) must be incremented when a large number of features have been added, or removed from the workflow. The patch and minor versions must be reset to 0 when major version is incremented (e.g. 1.9.3 -> 2.0.0).

Create a Backup of Existing Workfow

1. Access Ticket Application Administrative Interface.
2. Click Workflows.
3. Locate the desired workflow to be modified (e.g. Software Request 1.0.0). Make note of the associated Workflow ID (e.g. 70316).
4. In the Copy column click Copy.
5. A copy of the existing with will be created with the text "(Copy)" appended (e.g. Software Request 1.0.0 (Copy)).
6. Click the Workflow name to open the new version.
   1. If the workflow is Active then click the Deactivate button to disable the copy.
7. Click View Builder to open the Workflow Builder view.
8. In the Workflow Builder click File, then click Check Out.
9. In the Workflow Builder click Workflow, then click Details.
10. In the Edit Ticket Workflow dialog window update the Name of the workflow (e.g. Software Request 1.0.0) to remove the appended "(Copy)" text at the end of the name.
11. Click Save.
12. Under the File menu click Save and Check In.

Update/Edit a Workflow

Once a backup copy of a workflow is has been made, the following are generalized guidelines for updating/editing the workflow.

1. Access Ticket Application Administrative Interface.
2. Click Workflows.
3. Locate the desired (i.e. original) workflow to be modified (e.g. Software Request 1.0.0; ID: 70316).
4. Click the Workflow name to open to go to the detail page.
5. Click View Builder to open the Workflow Builder view.
6. In the Workflow Builder click File, then click Check Out.
7. In the Workflow Builder click Workflow, then click Details.
8. In the Edit Ticket Workflow dialog window update the Name of the workflow (e.g. Software Request 1.0.0 -> Software Request 1.1.0).
9. Click Save.
10. Proceed with modifying existing elements which call/activate the workflow, such as:
    • Automation Rules
    • Other Workflows
11. Occasionally during the editing process under the File menu, click Save Draft.
    Important

    Only click Save and Check In once all desired changes have been made, and its ready to be used in production.
12. Once all the desired changes have been made, under the File menu, click Save and Check In.

Frequently Asked Questions

How do I know when to release 1.0.0?

If the workflow is already being used in production, it should probably already be 1.0.0.

What do I do if I accidentally release a backward incompatible change as a minor version?

As soon as you realize that a minor change has introduced an incompatible change, fix the issue and release a new minor version that corrects the problem. Even in this circumstance, it is undesirable to simply modify the existing released version.

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start development release at 0.1.0 and then increment the minor version for each subsequent release.

Need additional help or have issues

For support, requests may be submitted anytime using the appropriate Enterprise Service Management form. Requests generate a Ticket which will be worked in order received and urgency by UA Employees with the knowledge and permissions to assist with the request.

For immediate assistance please review the Contact Us page for the appropriate support group.