Service Management plays an integral role in managing, delivering, and auditing changes across the pipeline, as well as tracking incidents that occur as part of the software delivery lifecycle. In this blog series I will showcase four use cases for integrating a FlexDeploy pipeline with ServiceNow.

In this use case we will make use of one change ticket per package in a release. To avoid users having to manually enter the change ticket numbers we will use “configuration by convention.” Specifically, we will will name the packages using the change ticket number. Configuration by convention is a useful technique to avoid having to store or collect additional metadata, creating a streamlined and efficient process.


This pipeline is a bit of a hybrid of the first two use cases.

Three pipeline stages in FlexDeploy: Dev, QA, Prod

The related ticket fields are set automatically by the Set Related Tickets Custom Gates. Unlike the second use case, this pipeline sets the related ticket at the package level. The Groovy script gets the packages in the snapshot, and sets the related ticket using each package name as the related ticket number.

Ticket fields are set automatically by the Set Related Tickets Custom Gates

The External Approval Gates are simple. They do not create tickets, but rather utilize the related ticket fields that are set by the custom gates.

QA Approval Gate in External Approval Gates

CAB Approval Gate in External Approval Gates


When creating the release we will follow the “convention” of setting the package names as the ServiceNow change ticket numbers.

Setting the package names as the ServiceNow change ticket numbers.

In Action!

I created a snapshot for the release containing builds for the two packages. Let’s look at what happens. The Set Related Tickets gate sets the package names as the related tickets for the respective packages. The pipeline is now waiting at the QA Approval gate for the two change tickets to be approved.

Pipeline waiting at the QA Approval gate for two change tickets to be approved.

Once both tickets are approved, the same Related Ticket fields are set into the production stage (by the Set Related Tickets custom gate). This time the gate passes immediately since the tickets are already approved. If different criteria is required to approve the tickets for production that logic can be implemented with the Approval Check Script on the CMS instance.

Both tickets are approved and set in the Production stage in FlexDeploy.


These are just three of many use cases which are made possible by the flexibility of the Change Management integration within FlexDeploy pipelines. The External Approval Gate, Custom Gate, CMS configuration, Snapshot Variables, and CMS Instance configuration offer endless options for creativity.

Next Post: FlexDeploy Service Management: Create Incident on Workflow Failure

Share this:
Erick Jones

I have been working with Java EE technologies for 25 years, and have applied industry experience implementing IBM and Oracle solutions. Through my architecture and development experience I have implemented several homegrown and third party automation solutions to manage the software delivery lifecycle. At Flexagon I am a DevOps evangelist, with a passion for helping customers deliver software to their customers faster, cheaper, and with higher quality. My primary focus is on FlexDeploy product strategy, and pre-sales and post-sales implementations.

More posts by Erick Jones

Leave a Reply

Your email address will not be published. Required fields are marked *