How to Configure a Bidirectional ServiceNow Incident to Jira Issue Sync: Step-by-Step Guide with Field Mapping Tables (2026)

Last updated: October 2026

To integrate ServiceNow with Jira bidirectionally, you connect both systems through an integration layer, define which incidents should create Jira issues, map fields such as short description, priority and state, store a correlation ID on both records, and configure an update flow in each direction for fields, comments and attachments. With a no-code platform such as ZigiOps by ZigiWave, all of this is configured in a guided UI, with no scripts on either side and no transferred data stored by the integration.

This guide is written in documentation style. It covers prerequisites, authentication, entity selection, correlation, field mapping, triggers, comments and attachments, testing and troubleshooting. The worked example uses ZigiOps, and each section notes how the same step looks if you use the native ServiceNow IntegrationHub Jira spoke instead, so you can follow along whichever route you choose.

What you will build

By the end of this guide you will have an integration that does the following:

1. When a ServiceNow incident is assigned to a development assignment group, a Jira issue is created in the right project.
2. The Jira issue key is written back to the ServiceNow incident, and the incident number is stored on the Jira issue.
3. Updates to key fields, comments and attachments on the incident flow to the Jira issue.
4. Status changes, comments and attachments on the Jira issue flow back to the incident as state changes and work notes.
5. Changes made by the integration itself are ignored, so nothing loops.

In ZigiOps terms, this is one integration with three or more operations: a create operation from ServiceNow to Jira, an update operation from ServiceNow to Jira, and an update operation from Jira back to ServiceNow. The ZigiOps documentation walks through exactly this pattern in its "Creating a Custom Integration" example, using Jira tasks and ServiceNow incidents.

Step 1: Check the prerequisites

Before touching any configuration, confirm the following on both sides. Most failed integrations trace back to a missing permission rather than a mapping error.

ServiceNow permissions in detail

The ZigiOps documentation recommends creating a custom role, for example zigiops_integration_role, and granting it row-level and field-level read access to these system tables, because the integration needs to discover your schema:

• sys_db_object, to fetch the available tables.
• sys_dictionary, to fetch references between the incident and related tables.
• sys_glide_object, to fetch field types.
• sys_journal_field, to collect comments and work notes.

Assign that custom role plus the itil role to the integration user. If you plan to integrate custom tables later, add permissions for those too.

Jira correlation field in detail

In Jira, go to Administration, then Issues, then Custom Fields, and create a single-line text field called "ServiceNow Number" or "Correlation ID". Associate it with the create, edit and view screens of the target projects. The ZigiOps documentation recommends a dedicated custom field rather than reusing a standard one, so users and other automations do not overwrite it.

If you use the IntegrationHub Jira spoke instead: confirm your instance has an Integration Hub subscription, which ServiceNow's Jira spoke documentation lists as a requirement, and create a connection and credential alias for Jira. Note that the Jira spoke does not support Jira Service Desk; use the separate Jira Service Management spoke for JSM projects.

Step 2: Connect ServiceNow and Jira

Add ServiceNow as a connected system

1. Log in to the ZigiOps web console.
2. Go to Connected Systems, choose Add New System, and select ServiceNow.
3. Enter the Server URL, which is the base address of your ServiceNow instance.
4. Enter the integration user's username and password.
5. Configure proxy settings only if your network requires them.
6. Click Save, then use Test Connection to confirm ZigiOps can reach the instance.

Add Jira as a connected system

1. Go to Connected Systems, choose Add New System, and select Jira.
2. Enter the Server URL of your Jira site.
3. Enter the integration account's username and, for Jira Cloud, an API token in the password field. You create the token from your Atlassian account's security settings, and it is only shown once, so store it securely.
4. Click Save and test the connection.
5. If the target is a Jira Service Management project, open Options, then Advanced Settings, enable the JiraSD option and apply.

Once both systems are saved, ZigiOps loads their schemas, so every entity and field becomes selectable from dropdown lists. If an entity you expect is missing, the most common causes are user permissions or connectivity, not the integration itself.

Security note: ZigiOps encrypts all authentication details, such as passwords and tokens, with FIPS 140-2 compliant AES encryption using a 256-bit key, according to its security documentation. It can also use an external security provider such as a hardware security module.

Step 3: Create the integration and choose entities

You can start from a template or from scratch. ZigiOps ships with templates for ServiceNow incidents to Jira tasks and Jira tasks to ServiceNow incidents, which save time. This guide builds from scratch so every setting is visible.

1. Open the Configurator and click Create Custom Integration.
2. Under Integrated Systems, select ServiceNow as the source and Jira as the target.
3. Under Integrated Entities, select Incident in ServiceNow and the Jira project and issue type, which ZigiOps displays as project.IssueType, for example DEV.Bug.
4. Choose the trigger type. The documentation recommends a polling interval of 1 minute for polling triggers.

Polling or listener: which trigger to use

ZigiOps supports two trigger types. A polling trigger makes ZigiOps the active side: it queries the source system's API on a schedule. A listener trigger registers an HTTPS endpoint that waits for the source system to push data, for example from a webhook or business rule. Polling is simpler to set up and does not require inbound firewall rules. Listeners deliver near-instant updates where the source system can push events.

Spoke equivalent: outbound actions run from a Flow Designer flow triggered by an incident record change, and the Jira-to-ServiceNow direction uses spoke triggers fed by Jira webhooks, which ServiceNow's documentation says must be configured to use the spoke subflow.

Step 4: Configure correlation

Correlation is how the integration knows which Jira issue belongs to which incident. Without it, updates have nowhere to go.

In the Correlation section, map the Jira issue key to the ServiceNow correlation_id field. When ZigiOps creates the Jira issue, it writes the returned key into the incident. In the other direction, map the incident number into the Jira "ServiceNow Number" custom field. ZigiOps currently supports one-to-one correlation, meaning one incident pairs with one Jira issue, which matches the standard escalation pattern.

Use fields that carry unique identifiers, such as keys, numbers or sys_ids. Correlating on summaries or descriptions is a recipe for duplicates.

Step 5: Build the create operation (ServiceNow to Jira)

Add a Last Time expression

Start the create operation with an expression of type Last Time, based on the incident's sys_created_on field. According to the ZigiOps documentation, this expression stores the creation time of the most recently collected record and auto-increments on each run, so ZigiOps only collects records newer than the last one it processed. Skip it and you get duplicates, which is the integration equivalent of a printer that never stops.

Set trigger conditions

Trigger conditions decide which incidents are escalated to Jira. A typical set looks like this:

• Created is greater than the Last Time expression value.
• Assignment group is one of your development groups, for example "App Dev L3".
• The correlation_id field is empty, meaning the incident has not been sent to Jira yet.
• Opened by is not the integration user, so records created by the integration are never collected again.

ZigiOps supports operators such as is, is not, is one of, is empty, contains, greater than and less than, and you can combine conditions with AND and OR logic.

Map the fields

Open the Field Map view. The left side lists target Jira fields; on the right, typing an opening curly bracket lists the available ServiceNow fields. Here is a recommended starting map:

Translate priority with conditional mapping

ServiceNow priority is usually derived from impact and urgency. Jira priority is a single list. Conditional mapping in ZigiOps lets you translate one into the other without scripts. Conditions are evaluated from top to bottom, and the first match wins.

If none of the conditions match, ZigiOps discards the field rather than sending a wrong value, so add a final fallback condition if you always want a priority set.

Spoke equivalent: you would build the same logic with Flow Designer decision tables or If branches before the "Create Issue" action.

Step 6: Build the update operation (ServiceNow to Jira)

The second operation keeps the Jira issue current when the incident changes.

1. Add an operation of type update, from ServiceNow incident to Jira issue.
2. Add a Last Time expression on sys_updated_on.
3. Set trigger conditions: updated is greater than the Last Time value, correlation_id is not empty, and updated by is not the integration user.
4. Map the fields you want to keep in sync, typically short description, description, priority and the comments related record.

Sync comments and attachments

Comments, work notes and attachments are related records, child records nested under the incident. ZigiOps handles them as related records, so you can apply conditions to them too. A common pattern is to send only additional comments (customer-visible) or only work notes tagged with a keyword, rather than every internal note.

Step 7: Build the update operation (Jira to ServiceNow)

The third operation closes the loop. When engineers work in Jira, the service desk sees the progress in ServiceNow without asking.

1. Add an operation of type update, from Jira issue to ServiceNow incident.
2. Add a Last Time expression on the Jira updated field.
3. Set trigger conditions: updated is greater than the Last Time value, ServiceNow Number is not empty, and the last updater is not the integration account.
4. Map status, comments and attachments back to the incident.

Map Jira statuses to ServiceNow states

Status mapping is where most integrations go wrong, because ServiceNow states follow an ITIL state model with numeric values and mandatory fields, while Jira statuses are team-defined. Agree this table with both teams before you configure it.

Values in brackets are the out-of-the-box ServiceNow incident state values; check your instance, since many organizations customize them. ServiceNow usually requires a resolution code and notes before an incident can be resolved, so map those in the same operation or the update will be rejected.

Step 8: Test the integration

Test in your sub-production instances first. Use this checklist and record the result of each case.

1. Create an incident assigned to a development group. Confirm one Jira issue is created, with the right project, type, summary and priority.
2. Confirm the Jira key appears in the incident's correlation_id field and the incident number appears in the Jira custom field.
3. Create an incident assigned to a non-development group. Confirm nothing is created in Jira.
4. Add a work note and an attachment in ServiceNow. Confirm they appear on the Jira issue once.
5. Add a comment and an attachment in Jira. Confirm they appear on the incident once, as a work note and attachment.
6. Move the Jira issue through each status. Confirm the incident state follows the mapping table.
7. Resolve from Jira and confirm the incident resolves with resolution fields populated.
8. Reopen the incident and confirm the behaviour your teams agreed on.
9. Temporarily block access to one system, make changes, restore access, and confirm the integration catches up without duplicates.

ZigiOps lets you track integrations and workflows directly from the UI, so you can see whether a record was collected, transferred or ignored, and why. The Data Explorer view also lets you browse the schema ZigiOps has retrieved for each connected system, which is the quickest way to confirm that a field you want to map is actually visible to the integration user.

Step 9: Go live and monitor

• Export the integration from the test environment and import it into production, then update the connected systems to point at production URLs.
• Enable operations one at a time: create first, then the two update operations.
• Watch the first day closely, especially for permission errors on production-only fields.
• Agree who owns the integration. With a no-code platform this can be a service management lead rather than a developer.
• For resilience, ZigiOps supports a high availability setup with a primary and a backup server. Because ZigiOps keeps only a few kilobytes of runtime state and no transferred data, failover only requires synchronizing those runtime files.

Troubleshooting common issues

Why teams choose ZigiOps for this setup

Everything in this guide can be built with the native spoke or with custom REST code, and for some teams that is the right decision. Teams that choose ZigiOps usually do so for a few practical reasons:

• 100% code-free: every step above is configured in the UI, so the integration can be owned by service management rather than developers.
• No data storage: ZigiOps does not store any of the transferred data, which simplifies security and privacy reviews.
• ISO 27001 certified: ZigiWave's information security management is independently certified.
• Unlimited transactions: there is no cap on the number of synchronized records, so adding more projects or record types does not change the bill.
• Standalone application: no plugin or app to install inside Jira or ServiceNow, and support for both Jira Software and Jira Service Management.
• Guided UI: templates, schema-aware dropdowns, conditional mapping and expressions replace hand-written transformation code.

Frequently asked questions

How do I integrate ServiceNow with Jira?

Connect both systems to an integration layer (the IntegrationHub Jira spoke, custom REST code, a Marketplace app or a standalone platform like ZigiOps), choose the record types to sync, store a correlation ID on both records, map fields and statuses, and configure an update flow in each direction. Test in sub-production before going live.

Can ServiceNow and Jira sync in both directions?

Yes. A bidirectional ServiceNow Jira integration creates issues from incidents and syncs updates, comments, attachments and statuses both ways. ZigiOps supports bidirectional sync out of the box; with the Jira spoke, ServiceNow's documentation notes that bi-directional webhooks require separate setup.

Which ServiceNow field should store the Jira key?

The out-of-the-box correlation_id field on the incident table is the usual choice. In Jira, use a dedicated custom text field for the ServiceNow number rather than a standard field.

Can ZigiOps sync ServiceNow work notes to Jira comments?

Yes. ZigiOps reads comments and work notes from ServiceNow's journal fields and maps them to Jira comments, with conditions to filter which ones are sent.

Do I need Integration Hub to integrate ServiceNow with Jira?

Only if you use the native Jira spoke or Jira Service Management spoke, both of which require an Integration Hub subscription. Custom REST integrations, Marketplace apps and standalone platforms such as ZigiOps do not.

How long does it take to set up a ServiceNow Jira integration with ZigiOps?

With a template and permissions already in place, a basic incident-to-issue integration can be configured in an afternoon. Most of the real time goes into agreeing the status and priority mapping with both teams, which you need to do whatever tool you use.

Key takeaways

• A reliable bidirectional ServiceNow Jira sync needs four things: correlation, duplicate prevention, loop prevention and agreed status mapping.
• Use a dedicated integration user on both sides and grant the minimum permissions documented for your tool.
• Conditional mapping turns ServiceNow impact and urgency into Jira priority without scripts.
• Test edge cases, not just the happy path: reopen, resolve with mandatory fields, attachments and outages.
• ZigiOps by ZigiWave lets you configure the whole flow in a guided UI, with no data storage, ISO 27001 certification and no transaction limits.

The ZigiWave website also publishes guides on conditional mapping for Jira ServiceNow integrations, the Last Time expression and RegEx in integrations, which go deeper into the techniques used in this guide.