> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/approvals/using-jira-and-service-now-approval-steps-in-cd-stages.md). # Using Jira and ServiceNow approval steps in CD pipelines Add Jira and ServiceNow approval steps that approve or reject a pipeline stage Add an approval stage, or an approval step in a stage, and use a Jira issue or a ServiceNow ticket as the criteria to approve or reject. Go to [Ticketing systems](https://developer.harness.io/docs/platform/connectors/ticketing-systems/) to connect Jira or ServiceNow. *** ## What you will learn from this topic * How to [add a Jira Approval step](#adding-jira-approval-stages-and-steps) in a Jira Approval stage or a Continuous Delivery stage * How to [pass a Jira issue key](#passing-jira-issue-keys-using-expressions) from a Jira Create or Jira Update step * How to [set Jira approval criteria](#step-2-set-approval-criteria) with conditions or a JEXL expression * How to [add a ServiceNow Approval step](#adding-servicenow-approval-steps-and-stages) in an Approval stage * How to [read ServiceNow approval outputs](#output) after the step approves or rejects *** ## Before you begin Create the connector for the ticketing system the approval step reads: * **Jira connector**: Go to [Connect to Jira](https://developer.harness.io/docs/platform/connectors/ticketing-systems/connect-to-jira/) to create the connector. Go to [Create Jira issues in CD stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/create-jira-issues-in-cd-stages.md) and [Update Jira issues in CD stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/update-jira-issues-in-cd-stages.md) when the approval evaluates an issue those steps create. * **ServiceNow connector**: Go to [Connect to ServiceNow](https://developer.harness.io/docs/platform/connectors/ticketing-systems/connect-to-service-now/) to create the connector. *** ## Jira approval stages and steps You can use Jira issues to approve or reject a Pipeline or stage at any point in its execution. During deployment, a Jira issue's fields are evaluated according to criteria you define and its approval/rejection determines if the Pipeline or stage may proceed. The **Jira Approval** step can be added in a Jira Approval stage or in a Continuous Delivery stage. The Jira Approval step prevents the stage execution from proceeding without an approval. For example, in a [Kubernetes Blue Green Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md), you might want to add an approval step between the Stage Deployment step, where the new app version is deployed to the staging environment, and the Swap Primary with Stage step, where production traffic is routed to the pods for the new version. To create or update Jira issues, go to [Create Jira issues in CD stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/create-jira-issues-in-cd-stages.md) and [Update Jira issues in CD stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/update-jira-issues-in-cd-stages.md). #### Visual summary The following video shows you how to use the Jira Create, Jira Update, and Jira Approval steps: {% embed url="" %} Use the Jira Create, Jira Update, and Jira Approval steps {% endembed %} #### Limitations The Jira Approval step reads a limited set of Jira field types: * Harness supports only Jira fields of type `Option`, `Array`, `Any`, `Number`, `Date`, and `String`. Harness does not integrate with Jira fields that manage users, issue links, or attachments. This means that Jira fields like Assignee and Sprint are not accessible in the Harness Jira integration. * Array-type fields (such as **Labels**) cannot be used in the **Conditions** section of approval criteria. Only string and option-type fields are supported for key-value criteria. To evaluate array-type fields, use JEXL expressions in the **JEXL Expression** field instead. For example, to check if a label exists, use `<+issue.Labels>.indexOf('your-label') >= 0`. #### Jira approval stages and steps You can use Jira Approvals in two ways: * **Jira Approval step**: You can add a Jira Approval step to any Continuous Delivery or Approval stage. * **Jira Approval stage**: The Jira Approval stage includes Jira Create, Jira Approval, and Jira Update steps: ![Jira Approval stage with Jira Create, Jira Approval, and Jira Update steps](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-91f30f09cfb948f825fa1d2a36469c8d1696cf31%2Fadding-jira-approval-stages-08.png?alt=media) You do not need to use the Jira Create and Jira Update steps with the Jira Approval step, but they are included in the Jira Approval stage because the stage is meant to create a Jira issue, approve or reject based on its settings, and then update the Jira issue in one stage. You can also use the Jira Create, Jira Approval, and Jira Update steps within a non-Approval stage. The Jira Create and Jira Update steps are described in other topics. This topic describes the Jira Approval step only. See: * [Create Jira Issues in CD Stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/create-jira-issues-in-cd-stages.md) * [Update Jira Issues in CD Stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/update-jira-issues-in-cd-stages.md) #### Add a Jira Approval step In a CD or Approval stage, click **Add Step**, and then click **Jira Approval**. When you add a Jira Approval stage, Harness automatically adds Jira Create, Jira Approval, and Jira Update steps. This topic covers only the Jira Approval step. In **Name**, enter a name that describes the step. In **Timeout**, enter how long you want Harness to try to complete the step before failing (and initiating the stage or step [Failure Strategy](https://developer.harness.io/docs/platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps)). You can use `w` for week, `d` for day, `h` for hour, `m` for minutes, `s` for seconds, and `ms` for milliseconds. For example, `1d` is one day. Jira communication can take a few minutes. Do not use a brief timeout. The maximum is 3w 3d 20h 30m. In **Jira Connector**, create or select the [Jira Connector](https://developer.harness.io/docs/platform/connectors/ticketing-systems/connect-to-jira/) to use. In **Project**, select the Jira project that contains the issue you want to evaluate. In **Issue Key**, enter the Jira issue key of the issue you want to evaluate. In **Retry Interval**, set how long the step should wait to fetch details again for calculating Approval or Rejection criteria. #### Pass Jira issue keys with expressions In **Issue Key**, you can use an expression to reference the issue key from another Jira Create or Jira Update step.
Example pipeline The following example shows a Jira Create step (with the Id `Jira_Create`) and two subsequent Jira Update steps, JiraUpdate\_1 and JiraUpdate\_2. JiraUpdate\_1 references the issue key from the Jira Create step using the expression `<+pipeline.stages.Jira_Stage.spec.execution.steps.Jira_Create.issue.key>`. JiraUpdate\_2 references the issue key from JiraUpdate\_1 using the expression `<+execution.steps.JiraUpdate_1.spec.issueKey>`, but it could also use the expression `<+pipeline.stages.Jira_Stage.spec.execution.steps.Jira_Create.issue.key>`. ```yaml pipeline: name: Jira identifier: Jira projectIdentifier: CD_Docs orgIdentifier: default tags: {} stages: - stage: name: Jira Stage identifier: Jira_Stage description: "" type: Approval spec: execution: steps: - step: name: Jira Create identifier: Jira_Create type: JiraCreate timeout: 5m spec: connectorRef: Jira projectKey: TJI issueType: Bug fields: - name: Summary value: test for doc - step: type: JiraUpdate name: JiraUpdate_1 identifier: JiraUpdate_1 spec: connectorRef: Jira issueKey: <+pipeline.stages.Jira_Stage.spec.execution.steps.Jira_Create.issue.key> transitionTo: transitionName: "" status: In Progress fields: [] timeout: 10m - step: type: JiraUpdate name: JiraUpdate_2 identifier: JiraUpdate_2 spec: connectorRef: Jira issueKey: <+execution.steps.JiraUpdate_1.spec.issueKey> transitionTo: transitionName: "" status: Will Not Fix fields: [] timeout: 10m tags: {} ```
The following video demonstrates how to pass an issue key: {% embed url="" %} Pass a Jira issue key between steps {% endembed %} The expression follows the format `<+pipeline.stages.STAGE_ID.spec.execution.steps.STEP_ID.issue.key>`. {% hint style="info" %} **Important** The Jira Create or Jira Update step you want to reference must be **before** the Jira Update step that references it in the pipeline and stage. {% endhint %} There are two ways to get the information for the expression: * **Use the standard expression**: In the Jira Update step **Issue Key**, select **Expression**, and then paste the expression `<+pipeline.stages.STAGE_ID.spec.execution.steps.STEP_ID.issue.key>` with the correct `STAGE_ID` and `STEP_ID` values for the Jira Create step that creates the issue key. ![Expression option selected for the Issue Key field](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-ab592a11a1000e96ee1f8f2f0efbb203f4ca9b21%2Ff1e2ce091ba77fae22dbafbd06e9e2a994a13850118aa1700043c126f53eda7c.png?alt=media)

When the Jira Create step is open in Pipeline Studio, copy the STAGE_ID and STEP_ID values from the browser URL: stageId=STAGE_ID&sectionId=EXECUTION&stepId=steps.0.step.STEP_ID.

For example, stageId=Jira_Stage&sectionId=EXECUTION&stepId=steps.0.step.Jira_Create.

* **Copy the expression from an executed step**: Select a successful execution, and click the Jira Create step in the execution. * Click the **Output** tab, locate the **Key** setting, and click the copy button. ![Output tab showing the issue key to copy](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5fdab13b7cde0552a6384330f8a440bb2af59bc4%2Fadding-jira-approval-stages-09.png?alt=media) Now you have the expression that references the issue key from this step. Go back to the Jira Update step. Select **Edit Pipeline**. In **Issue Key**, select **Expression**. ![Expression pasted into the Issue Key field](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-4ba0064c7ee95f2dd7d8aabc2f55ff1c23241358%2Fadding-jira-approval-stages-10.png?alt=media) In **Issue Key**, paste in the expression you copied from the previous Jira Create/Update step. With either method, the Jira Update step will use the issue created by the Jira Create step. A Jira Create step creates a new, independent Jira issue every time it runs. If you use the same issue ID in Jira Approval, each run approves a new issue. #### Set approval criteria The **Approval Criteria** in the step determines if the Pipeline or stage is approved or rejected. ![Approval criteria with conditions and a JEXL expression](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-2f2a32370604d0bcd5c2c712d866bab88566c798%2Fadding-jira-approval-stages-11.png?alt=media) Whether the Pipeline/stage stops executing depends on the stage or step [Failure Strategy](https://developer.harness.io/docs/platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps). You can specify criteria using **Conditions** and/or **JEXL Expression**. If you use them in combination they both must evaluate to `True` for the step to be successful. In **Conditions**, use the Jira field, operator, and value to define approval criteria. Four supported operators are `=`, `!=`, `in`, and `not in`. For example: * The condition for the `Status` field to be in `Approved`, `Done`, or `Published` can be specified as: ![Status in Approved, Done, or Published](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-037ca1ac81b847482cf29f1f4731396dbb929fbf%2Fadding-jira-approval-stages-15.png?alt=media) * The condition for the `Status` field to not be in either `Blocked`, `Invalid`, or `To Do` can be specified as: ![Status not in Blocked, Invalid, or To Do](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-21f38eb0b429b9502d0c78abf4d6968bbe702b46%2Fadding-jira-approval-stages-16.png?alt=media) * The condition for the `Status` field to be in `Approved`, `Done`, or `Published` without `Issue Type` can be specified as: ![Status in Approved, Done, or Published with no Issue Type](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-3f0d8fa1dc2b25a23c7bf4c6ef2daeb420935965%2Fadding-jira-approval-stages-17.png?alt=media) {% hint style="info" %} **Important** Multiple conditions with the same Jira field are not allowed. Such use cases can be solved using `in`, `not in` operators, or **JEXL Expression**. {% endhint %} In **JEXL Expression**, you can use [JEXL expressions](https://commons.apache.org/proper/commons-jexl/reference/syntax.html). You can use a JEXL expression if the field is set to **Fixed value**, **Runtime input**, or **Expression**. **Using JEXL expressions for array-type fields** Array-type fields like **Labels** cannot be evaluated using the **Conditions** section. Instead, use JEXL expressions to check these fields. For example, to approve when a specific label exists on the Jira issue: ``` <+issue.Labels>.indexOf('your-label') >= 0 ``` This expression returns `true` if the Labels array contains "your-label". **Additional examples**: * Check if Labels contains "fed": ``` <+issue.Labels>.indexOf('fed') >= 0 ``` * Check if Labels contains "approved" OR "verified": ``` <+issue.Labels>.indexOf('approved') >= 0 || <+issue.Labels>.indexOf('verified') >= 0 ``` * Check if Labels contains "high-priority" AND Status is "Done": ``` <+issue.Labels>.indexOf('high-priority') >= 0 && <+issue.Status> == "Done" ``` #### Set rejection criteria In **Optional Configuration**, in **Rejection Criteria**, you can define criteria for rejecting the approval. If you add rejection criteria it is used in addition to the settings in **Approval Criteria**. #### Advanced settings In Advanced, you can use the following options: * [Step Skip Condition Settings](https://developer.harness.io/docs/platform/pipelines/step-skip-condition-settings) * [Step Failure Strategy Settings](https://developer.harness.io/docs/platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps) #### Apply and test Click **Apply Changes**. The Jira Update step is added to the stage. Run the Pipeline. When the Jira Approval step is reached, you can see its approval and rejection criteria: ![Jira Approval step showing approval and rejection criteria during execution](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-b84ed9c638941f03e8798552f2cd3e587e2d3fb9%2Fadding-jira-approval-stages-12.png?alt=media) You can also click the **JIRA Ticket Pending Approval** link to open the ticket. The step can take a few minutes to receive information from Jira. #### Issue expressions You can use `<+issue>` to refer to the value in the **Issue Key** setting. For example, `<+issue.Status> == "Done"` in the Approval Criteria **JEXL Expression** checks whether the status of the issue in **Issue Key** is **Done**: ![JEXL expression checking that issue status is Done](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-8565230f43d927ae1a9984a0bce6a97f36ea228b%2Fadding-jira-approval-stages-13.png?alt=media) `Status` is an issue field. You can use any issue field. **Referencing JIRA fields with spaces or special characters** When referencing JIRA custom fields that contain spaces or special characters in their names, you must enclose the field name in **single quotes** (`'`) within the Harness expression. Without quotes, the expression evaluation will fail. **Examples**: **Fields with spaces, correct syntax**: ``` <+issue.'Risk Level'> == "High" <+issue.'1-line Update'> == "test" <+issue.'Remaining Estimate'> == "2h" ``` **Fields without spaces, no quotes needed**: ``` <+issue.Priority> == "P1" <+issue.Status> == "Done" <+issue.Description> == "new description" ``` **Complex expression combining both**: ``` ((<+issue.'Risk Level'> == "High") && (<+issue.Labels>.indexOf('crm-approved') >= 0)) || (<+issue.'Risk Level'> == "Low") ``` This expression checks if: * The "Risk Level" custom field equals "High" AND the Labels field contains "crm-approved", OR * The "Risk Level" custom field equals "Low" **Incorrect syntax (the expression fails)**: ``` <+issue.Risk Level> == "High" // FAILS - no quotes around field name with space <+issue.customfield_1234> == "High" // May work for custom field IDs, but use field names with quotes for better readability ``` {% hint style="info" %} * Use single quotes (`'`) around field names that contain spaces or special characters * Standard field names without spaces (like `Status`, `Priority`, `Labels`) do not require quotes * For better readability, use the custom field name with quotes rather than the `customfield_XXXX` identifier {% endhint %} **Additional examples**: ``` <+issue.Priority> == "P1" && <+issue."1-line Update"> == "test" && <+issue."Remaining Estimate"> == "2h" && <+issue.Description> == "new description" ``` #### Refresh status during execution You can do a **manual status refresh** in the Pipeline Studio Execution view. When the step is waiting for a response from Jira, you can use the **Refresh** button to immediately fetch the **latest status of the approval ticket** instead of waiting for the polling interval. Use the refresh option when: * The approval condition in Jira was updated after the step began execution. * You need quicker response handling for fast-track approvals such as incident mitigations or emergency changes. To use the refresh button: * Execute a pipeline with a Jira Approval step. * In the Pipeline Studio Execution view, locate the approval step. * If the step is in a waiting state, click the Refresh button. * The step re-evaluates the condition and proceeds if the criteria are met. #### Notes * To add comments in you can use **Comment** key. Use `\\` for line breaks. ![Comment key used to add a comment on the Jira issue](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-373ffcdcbb74ac61a0c41b13d49833a8629c8a35%2Fadding-jira-approval-stages-14.png?alt=media) * For more information about approval log limitations, go to [Deployment logs and limitations](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-logs-and-limitations.md). *** ## ServiceNow approval steps and stages You can use ServiceNow tickets to approve or reject a Pipeline or stage at any point in its execution. During deployment, a ServiceNow ticket's fields are evaluated according to the criteria you define, and its approval/rejection determines if the Pipeline or stage may proceed. Approvals can be added as stages or in-between stage steps to prevent stage execution from proceeding without approval. For example, in a [Kubernetes Blue Green Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md), you might want to add an approval step between the Stage Deployment step, where the new app version is deployed to the staging environment, and the Swap Primary with Stage step, where production traffic is routed to the pods for the new version. #### ServiceNow approval stages and steps You can use ServiceNow Approvals in two ways: * **ServiceNow Approval step**: You can add a ServiceNow Approval step to any pipeline or Approval stage. * **ServiceNow Approval stage**: The ServiceNow Approval stage. ![ServiceNow Approval stage](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-96531cff06a53f8897fd73a9d310aa947e554a96%2Fservice-now-approvals-00.png?alt=media) #### UTC timezone only The ServiceNow API only allows date time and time values in the UTC timezone. Consequently, input for any datetime/time fields in Harness ServiceNow steps must be provided in UTC format irrespective of time zone settings in your ServiceNow account. The timezone settings govern the display value of the settings not their actual value. The display values in the Harness UI depend on ServiceNow timezone settings. #### Add an approval step In your Pipeline, click **Add Stage**. ![Add Stage in the pipeline](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5717142fce8f4eb203be584f2070e2a0c2680bb2%2Fservice-now-approvals-01.png?alt=media) Click **Approval**. The Stage settings appear. ![Approval selected as the stage type](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-f9183ab6962bcd30d4819bc77bcc505eda33d108%2Fservice-now-approvals-02.png?alt=media) In **Name**, enter a name for your Stage and select **ServiceNow** as approval type. Click **Setup Stage**. The pipeline appears. In the pipeline, click **ServiceNow Approval.** The **ServiceNow Approval** settings appear. ![ServiceNow Approval step settings](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-1f1445e523002352a48fb39978fd0f812340b5cd%2Fservice-now-approvals-03.png?alt=media) In **Timeout**, enter how long you want Harness to try to complete the step before failing (and initiating the stage or step [Failure Strategy](https://developer.harness.io/docs/platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps)). You can use `w` for week, `d` for day, `h` for hour, `m` for minutes, `s` for seconds, and `ms` for milliseconds. For example, `1d` is one day. ServiceNow communication can take a few minutes. Do not use a brief timeout. The maximum is 3w 3d 20h 30m. In **ServiceNow** **Connector,** create or select the [ServiceNow Connector](https://developer.harness.io/docs/platform/connectors/ticketing-systems/connect-to-service-now/) you want to use. Select the ServiceNow **Ticket Type**. Use the same type as the ticket you created in the Workflow. Enter the ServiceNow **Ticket Number**. In **Retry Interval**, set how long the step should wait to fetch details again for calculating Approval or Rejection criteria. #### Set ServiceNow approval criteria The **Approval Criteria** in the step determines if the Pipeline or stage is approved or rejected. Define the approval criteria using the ServiceNow status items. ![ServiceNow approval criteria](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-2d09c1c4ccac51d2551766c7f0fe85b17ff13e41%2Fservice-now-approvals-04.png?alt=media) Whether the Pipeline/stage stops executing depends on the stage or step [Failure Strategy](https://developer.harness.io/docs/platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps). You can specify criteria using **Conditions** and/or **JEXL Expression**. If you use them in combination, they both must evaluate to `True` for the step to be successful. In **Conditions**, you can use the ServiceNow ticket related fields to define approval criteria. Four supported operators are `=`, `!=`, `in`, and `not in`. For example, * The condition for the `State` field to be in `Resolved`, `Closed`, or `Cancelled` can be specified as: ![State in Resolved, Closed, or Cancelled](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-bfe6f08196f5ba9dc13819dcbe18301b34b0de66%2Fservice-now-approvals-08.png?alt=media) * The condition for the `State` field to not be in either `New`, `In Progress`, or `On Hold` can be specified as: ![State not in New, In Progress, or On Hold](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-c0578821ce2af8c78c651343cf8582467829aa99%2Fservice-now-approvals-09.png?alt=media) * The condition for the `State` field to be in `Resolved`, `Closed`, or `Cancelled` without fixed `Ticket Type` can be specified as: ![State in Resolved, Closed, or Cancelled with no fixed Ticket Type](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-1eb42145e36393c67a89dff964d999d5069413e6%2Fservice-now-approvals-10.png?alt=media) {% hint style="info" %} **Important** Multiple conditions with the same Jira field are not allowed. Such use cases can be solved using `in`, `not in` operators, or **JEXL Expression**. {% endhint %} In **JEXL Expression**, you can use [JEXL expressions](https://commons.apache.org/proper/commons-jexl/reference/syntax.html). You can use a JEXL expression if the field is set to **Fixed value** or **Expression**. #### Set ServiceNow rejection criteria In **Optional Configuration**, in **Rejection Criteria**, you can define criteria for rejecting the approval. Define the rejected criteria using the ServiceNow status items. If you add rejection criteria, it is used in addition to the settings in **Approval Criteria**. #### Approval change window In **Approval Change Window**, use **Window Start** and **Window End** values to specify the window in which Harness will proceed with the deployment. Once this step is approved, Harness proceeds with deployment if the current time is within this window. The values that appear depend on the type selected in **Ticket Type**. ![Approval change window start and end](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-2f8963947fbe9a09e16ef15ef50eb54e41f2f5a2%2Fservice-now-approvals-05.png?alt=media) The start and end times use the time zone set in the ServiceNow account selected in the ServiceNow Connector. #### ServiceNow advanced settings In **Advanced**, you can use the following options: * [Delegate Selector](https://developer.harness.io/docs/platform/delegates/manage-delegates/select-delegates-with-selectors/) * [Step Skip Condition Settings](https://developer.harness.io/docs/platform/pipelines/step-skip-condition-settings) * [Step Failure Strategy Settings](https://developer.harness.io/docs/platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps) #### Apply and test the ServiceNow approval Click **Apply Changes**. The ServiceNow approval step is added to the stage. Run the Pipeline. When the ServiceNow Approval step is reached, you can see its approval and rejection criteria: ![ServiceNow Approval step showing approval and rejection criteria during execution](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-dbe092b3b76ca9ada83fd580e512231aa13baaef%2Fservice-now-approvals-06.png?alt=media) #### ServiceNow ticket expressions You can use `<+ticket>` to refer to the value in the **JEXL Expression** setting. For example, `<+ticket.state.displayValue> == "New"` in the Approval Criteria, **JEXL Expression** checks to see if the status of the ticket is **New.** ![JEXL expression checking that the ticket state is New](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5b2c15755d64c14d7c76a59cdd5b422b5b05a348%2Fservice-now-approvals-07.png?alt=media) `state` is a ticket field. You can use any ticket field. #### Refresh ServiceNow status during execution You can do a **manual status refresh** in the Pipeline Studio Execution view. When the step is waiting for a response from ServiceNow, you can use the **Refresh** button to immediately fetch the **latest status of the approval ticket** instead of waiting for the polling interval. Use the refresh option when: * The approval condition in ServiceNow was updated after the step began execution. * You need quicker response handling for fast-track approvals such as incident mitigations or emergency changes. To use the refresh button: * Execute a pipeline with a ServiceNow Approval step. * In the Pipeline Studio Execution view, locate the approval step. * If the step is in a waiting state, click the Refresh button. * The step re-evaluates the condition and proceeds if the criteria are met. #### Output Regardless of whether the step is approved or rejected, the **ServiceNow approval step** provides outputs that reference the details of the step, such as: * `ticketType` * `ticketNumber` * `Approval Criteria` * `Rejection Criteria` * `Conditions` * `hasApprovalCriteriaMet` * `hasRejectionCriteriaMet` These outputs can be used as **output variables** and referenced in subsequent steps or stages. Here are a few expression examples that can be used to fetch the output values: * **ticketType**: `<+pipeline.stages.stage.spec.execution.steps.ServiceNowApproval_1.output.ticketType>` * **ticketNumber**: `<+pipeline.stages.stage.spec.execution.steps.ServiceNowApproval_1.output.ticketNumber>` * **approvalCriteria**: `<+pipeline.stages.stage.spec.execution.steps.ServiceNowApproval_1.output.approvalCriteria.type>` * **rejectionCriteria**: `<+pipeline.stages.stage.spec.execution.steps.ServiceNowApproval_1.output.rejectionCriteria.type>` ![ServiceNow approval step output variables in the execution logs](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-597acb7657f72a736588239b1028a198c93223c4%2Fsnow-output-logs.png?alt=media) #### Logs You can also view detailed logs that describe why the validation **failed** or **succeeded** in the **ServiceNow approval step**. Here are examples of logs for different scenarios: * **Log example for an approved step**:\ The logs show the approval criteria on which the step was approved and the evaluating condition.\ ![Logs for an approved ServiceNow Approval step](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-59588bda3bdfc8f6ad6b78d07b9b5faf686dd853%2Fsnow-approval-logs.png?alt=media) * **Log example for a rejected step**:\ The logs show the rejection criteria on which the step was rejected and the evaluating condition.\ ![Logs for a rejected ServiceNow Approval step](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5e3e4c5ed1d573c793490b2042a4a6eb1c34791f%2Fsnow-rejection-logs.png?alt=media) * **Log example for using JEXL expression in approval criteria**:\ The logs show the JEXL expression on which the step is approved or rejected and how the condition is evaluated.\ ![Logs for a JEXL expression in ServiceNow approval criteria](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-199c75687b0c3b02150bd31868686000d61dc030%2Fsnow-approval-jexl-expression.png?alt=media) #### Custom table support For details, go to **Custom table support** in [Create ServiceNow tickets in CD stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/ticketing-systems/create-service-now-tickets-in-cd-stages.md#custom-table-support). #### ServiceNow notes * For more information about approval log limitations, go to [Deployment logs and limitations](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-logs-and-limitations.md). *** ## Next steps * [Using manual Harness approval stages](https://developer.harness.io/docs/platform/approvals/adding-harness-approval-stages/): Approve or reject a pipeline with a Harness user group. * [Using manual Harness approval steps in CD stages](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/approvals/using-harness-approval-steps-in-cd-stages.md): Add a Harness Approval step in a Continuous Delivery stage. {% @harness-feedback/feedback %}