External Approval Gate

The External Approval gate blocks stage execution until the attached change ticket(s) are approved or rejected. Change tickets can also be automatically created by External Approval Gate if Create Ticket is checked. Change Ticket can be defined per Project/Package combination or single for all Project/Packages in Snapshot. User must enter Change Ticket as necessary on Stage Execution Information if Create Ticket is not checked. Change Ticket can also be set using Custom Gate if necessary, see details later in this page.

Additionally, this gate also creates a task for the group members of the associated override role, which allows for an override of the gate if necessary. Gate override is allowed by override role only if release setting does not prohibit override of external gate.

Administrators can always approve or reject this gate.

Change ticket can be entered (or created automatically) on stage execution information page.

When all entered change tickets are approved in external change management system, gate will be approved.

When any change ticket is rejected then gate will be rejected.

Even when change tickets are only entered on few of the project(s) / package(s) and not on main change ticket, gate will be approved.

Field	Description

Field	Description
Name	The name of the gate.
Description	An optional description for the gate.
Override Role	The pipeline role which is allowed to approve or reject the gate in FlexDeploy outside of the Change Management System. Provides mitigation in event that CMS is unavailable for any reason. Approval tasks are created for the group members of this role, and will be automatically approved or rejected based on the status of the associated change ticket. If no group member is assigned to the role, the task is assigned to a group designated as a FlexDeploy Administrator. Optionally, use a Groovy expression to make this field dynamic based on some contextual value (e.g. a property defined on the pipeline, and specified on the release). When using a role script you can dynamically return a key/value pair. For example `return [type: 'groupName', value: 'FD Administrators']`. Supported types are `roleId`, `roleName`, `groupId`, and `groupName`. You can return Map with single key/value pair or list of such single key/value maps. If not specified, only a FlexDeploy Administrator can approve or reject the gate.
CMS Instance	The Change Management System instance to use for this external gate. See Integrations page to configure change management system integration.
Create Ticket	Determines whether to automatically create a CMS ticket when this gate is executed. If unchecked, it is expected that the related ticket fields for either the stage or the individual projects/packages is populated (either manually by the user or through a Custom Gate).
Precondition	An optional Groovy script that determines whether the gate or step is applicable during execution. The script has access to variables and methods listed in Pipeline Groovy Variables and Methods. You can find these variables and methods while using the Groovy Editor. The script must return true if the gate is applicable, or false otherwise. If no script is provided, the default is to return true (applicable).
Scope	Only applies when Create Ticket is checked. Determines the scope for setting the created change ticket. If scope is Stage, the change ticket field of the stage is updated to the created change ticket. If scope is Project/Package, a change ticket will be created or each project/package in the snapshot and the corresponding change ticket field is updated.
<Ticket Fields>	Only applies when Create Ticket is checked. Used to set the values of individual ticket fields when creating a ticket. By default, the ticket field mapping comes from the global configuration. Use a Groovy expression to the values for the individual ticket fields and make them dynamic based on some contextual value (e.g. a property defined on the pipeline, and specified on the release).

One common use case is to propagate the ticket number entered or created in one stage across into future stage(s) to avoid duplicate effort. This can be implemented by having a snapshot variable (e.g. CMS_TICKET) on the pipeline to hold the ticket, and a custom gate after the external approval gate to store the ticket number into the variable. The future stage can use another Custom Gate to set the related ticket from the value of the snapshot variable.

// Initial Stage in a Custom Gate
CMS_TICKET = stgexecinfo.getRelatedTicket()

// Subsequent Stage in a Custom Gate
stgexecinfo.setRelatedTicket(CMS_TICKET)