Syncing Attachments, Priorities and Comments Between Jira and ServiceNow: A Technical Guide
Last updated: November 2026
To sync attachments, priorities and comments between Jira and ServiceNow reliably, treat each as its own mapping problem. Attachments need size and type filters plus a record of what has already been transferred, so files are not uploaded twice. Priority needs an explicit translation table between ServiceNow's impact and urgency matrix and Jira's single priority field. Comments need a rule that keeps ServiceNow work_notes and Jira internal comments private, while customer-facing comments travel only where they belong. In ZigiOps, the no-code integration platform by ZigiWave, each of these rules is configured in the mapping UI instead of in scripts.
Most Jira ServiceNow integration projects get the basics working quickly. An incident creates an issue, the keys are stored on both sides, and status changes flow back. The problems usually appear a few weeks later. An engineer cannot find the log file the service desk attached. A P1 incident shows up in Jira as "Medium". A private work note about a customer ends up visible on a public Jira Service Management portal. These are the three fields that break most often in any bidirectional sync.
Why these three fields break most often
Simple text fields such as short description or summary are one-to-one: one value in, one value out. Attachments, priorities and comments are different, for three reasons.
- They are not single values. Attachments and comments are lists that grow over time. The integration has to know which items it has already sent, not just the current state of the record.
- They are modelled differently on each side. ServiceNow calculates priority from two inputs, while Jira stores one. ServiceNow splits comments into two journal fields, while Jira uses one comment stream with visibility settings.
- They carry risk. Attachments can contain customer data, large binaries or files your security team blocks. Comments can contain internal discussion that must never reach a customer.
Part 1: Syncing attachments between ServiceNow and Jira
How attachments are stored on each side
In ServiceNow, attachments are not stored on the incident record itself. They live in the sys_attachment table, linked to the parent record by table name and sys_id, with the file content held in related attachment document records. Any integration that reads attachments has to query sys_attachment for the incident's sys_id and then download each file.
In Jira, attachments belong to the issue and appear in its attachment field. Uploads through the REST API use a multipart request, and Jira Cloud and Data Center differ slightly, so check the documentation for your edition.
| Aspect | ServiceNow | Jira |
|---|---|---|
| Where files are stored | sys_attachment table, linked by table_name and table_sys_id | On the issue, listed in the attachment field |
| Size limit | Set by a system property for maximum attachment size; check your instance | Set by the attachment size setting in Jira administration; check your site |
| Type restrictions | Can be restricted by allowed or blocked extension properties | Generally fewer restrictions by type, but admins and security tools may block some |
| Unique identifier | sys_id of the attachment record | Attachment ID returned by Jira |
| Deletion | Deleting removes the sys_attachment record | Deleting removes the file from the issue |
Problem 1: duplicate uploads
The most common attachment bug is duplication. A naive integration checks the incident on every update, sees three attachments, and sends all three again. After ten updates the Jira issue has thirty files. Comparing file names is not enough either, because users often upload several files called "screenshot.png".
Rule: keep a record of transferred attachments by their source identifier. The integration should remember that ServiceNow attachment sys_id X became Jira attachment ID Y, and only send attachments whose source ID has not been seen before. Some tools do this automatically by tracking the last sync time and sending only attachments created after it. Others need you to store the mapping yourself.
How this works in ZigiOps: ZigiOps syncs attachments as related records of the incident and the issue, in both directions. Its Last Time expression collects only records created since the previous run, so files that ZigiOps has already transferred are not sent again.
Problem 2: files that are too large or not allowed
If ServiceNow allows larger files than Jira does, or the other way round, a sync will fail silently or loudly depending on the tool. A failed upload can also block the rest of the update if the integration treats it as a fatal error.
Rule: set the integration's attachment limit to the smaller of the two platforms' limits, and filter by type. Agree a short list of allowed extensions with security. When a file is skipped, post a comment or work note saying so, so nobody assumes the file arrived.
Problem 3: sensitive content
Agents often attach exports or screenshots containing personal data, and in Jira those files are visible to the whole project.
Rule: decide whether all attachments should sync or only some. Common patterns are to sync only attachments added after the incident is escalated, to sync only specific file types such as logs, or to require an agent to tick a flag before files are sent.
Example attachment rules
| Rule | ServiceNow to Jira | Jira to ServiceNow |
|---|---|---|
| Which files | Attachments added after the incident is assigned to a development group | All attachments added by engineers after the issue is created |
| Allowed types | .log, .txt, .png, .jpg, .pdf, .zip | .log, .txt, .png, .jpg, .pdf |
| Maximum size | The lower of the two platform limits | The lower of the two platform limits |
| Duplicate check | Source sys_id stored against the Jira attachment ID | Jira attachment ID stored against the sys_attachment sys_id |
| Skipped file | Comment added to the Jira issue naming the skipped file | Work note added to the incident naming the skipped file |
| Deletions | Not synced (deleting in one system does not delete in the other) | Not synced |
Not syncing deletions is the safer default: an accidental delete would otherwise remove evidence from both systems.
Part 2: Mapping ServiceNow priority to Jira priority
How priority works in ServiceNow
ServiceNow incidents do not usually have a priority that people set directly. Agents set impact and urgency, each typically on a scale of 1 (High) to 3 (Low), and a priority lookup rule calculates priority from the combination. On a default instance this produces priorities from 1 (Critical) to 5 (Planning). Many organisations customise the matrix, so check the priority lookup rules on your instance before designing the mapping.
How priority works in Jira
Jira has a single priority field. The default scheme includes Highest, High, Medium, Low and Lowest, but administrators can create custom priority schemes per project, with different names and numbers of levels. Jira Service Management projects may also use impact and urgency fields together with automation rules to calculate priority, which creates a second matrix to align with.
Problem: one field versus two
The forward direction is simple: read the calculated priority and translate it. The reverse is the problem. If an engineer raises a Jira issue from Medium to Highest, which ServiceNow field should change? You cannot write priority directly on most instances, because it is calculated. You have to set impact and urgency to values that produce the right result.
Rule: decide which system owns priority. In most incident escalation flows, ServiceNow owns it, because the service desk is accountable for the SLA. Jira priority is then read-only from the integration's point of view: changes in ServiceNow flow to Jira, but engineers' changes in Jira do not flow back. If you need two-way priority, define a reverse table that maps each Jira priority to a fixed impact and urgency pair.
How this works in ZigiOps: ZigiOps handles this with conditional mapping. Each condition checks the impact and urgency values and sets the matching Jira priority. If no condition matches, ZigiOps does not send a value, so add a fallback condition if you always want a priority set.
Example priority mapping
| Impact | Urgency | ServiceNow priority | Jira priority | Reverse mapping (Jira to ServiceNow) |
|---|---|---|---|---|
| 1 - High | 1 - High | 1 - Critical | Highest | Highest sets impact 1, urgency 1 |
| 1 - High | 2 - Medium | 2 - High | High | High sets impact 1, urgency 2 |
| 2 - Medium | 1 - High | 2 - High | High | Not used in reverse |
| 2 - Medium | 2 - Medium | 3 - Moderate | Medium | Medium sets impact 2, urgency 2 |
| 1 - High or 3 - Low | 3 - Low or 1 - High | 3 - Moderate | Medium | Not used in reverse |
| 2 - Medium or 3 - Low | 3 - Low or 2 - Medium | 4 - Low | Low | Low sets impact 2, urgency 3 |
| 3 - Low | 3 - Low | 5 - Planning | Lowest | Lowest sets impact 3, urgency 3 |
The forward direction maps on the calculated priority value, so you do not need to read impact and urgency at all. The reverse direction picks one representative pair per Jira priority. Document this choice so agents understand why impact and urgency changed when an engineer changed the priority.
Edge cases to plan for
- Custom Jira priority schemes. If different Jira projects use different schemes, you need one mapping table per project. A single global table will fail for projects that do not have "Highest".
- Priority changes during a major incident. If ServiceNow priority changes from 3 to 1 mid-incident, make sure the update flow includes priority, not just the create flow. Many first-version integrations only set priority at creation.
- Unmapped values. Always define a default. If a value has no mapping, set Medium and add a comment, rather than failing the whole update.
Part 3: Syncing comments and work notes
How comments work on each side
ServiceNow stores two kinds of journal entries on an incident. Additional comments (the comments field) are customer-visible and appear on the portal and in notifications to the caller. Work notes (the work_notes field) are internal and visible only to fulfillers. Both are stored as journal entries, which an integration reads from the journal field table.
Jira Software has a single comment stream. Comments can be restricted to a project role or group, which hides them from other users. Jira Service Management adds a clear split: "Reply to customer" comments are public and appear on the portal, while "Add internal note" comments are visible only to agents.
| Visibility | ServiceNow | Jira Software | Jira Service Management |
|---|---|---|---|
| Customer-visible | Additional comments (comments) | No customer concept by default | Public comment (reply to customer) |
| Internal only | Work notes (work_notes) | Comment restricted to a role or group | Internal comment |
| Author | The user who added the journal entry | The user who added the comment, or the integration user | The user who added the comment, or the integration user |
Problem 1: leaking internal notes
The most serious comment problem is visibility. If work_notes are mapped to public comments in a JSM project, internal discussion appears on the customer portal. If public Jira comments are mapped to ServiceNow additional comments, engineers' technical chatter is emailed to the caller.
Rule: map work_notes only to internal or restricted comments, and map public Jira comments to work_notes by default, not to customer-facing comments. Let the service desk decide what the customer hears. If engineers need to write to the customer directly, use an explicit marker, such as a comment that starts with a tag the integration recognises, and route only those to additional comments.
Problem 2: comment loops and echoes
When a comment syncs from ServiceNow to Jira, the integration user creates a new Jira comment. If the reverse flow does not ignore comments created by the integration user, that comment comes straight back to ServiceNow as a new work note, and the cycle repeats.
Rule: filter out comments created by the integration user in both directions. Most tools have a setting for this. In custom code, check the author before sending.
How this works in ZigiOps: ZigiOps reads comments and work notes from ServiceNow's journal fields and maps them to Jira comments. Conditions on author and type decide which entries are sent, so the integration user's own comments are skipped and work notes stay internal.
Problem 3: lost authorship
Because the integration user creates every synced comment, the receiving side shows the integration account as the author. Engineers then cannot tell who in the service desk wrote a note.
Rule: prepend the original author and time to the synced comment body, for example "[ServiceNow work note by J. Smith, 14:32] Customer confirmed the error after the restart." This is simple, works on every platform, and makes audit trails readable.
Example comment rules
| Source | Target | Format | Filter |
|---|---|---|---|
| ServiceNow work_notes | Jira internal or restricted comment | Prefix with author name and time | Skip entries created by the integration user |
| ServiceNow comments (additional comments) | Jira internal comment | Prefix with "Customer-visible comment from ServiceNow" | Skip entries created by the integration user |
| Jira comment (any) | ServiceNow work_notes | Prefix with author name and time | Skip comments created by the integration user |
| Jira comment starting with a public marker | ServiceNow comments (additional comments) | Remove the marker before sending | Only when the marker is present |
Real-time sync versus polling
Teams often want real time sync between ServiceNow and Jira for comments. Webhooks and ServiceNow business rules or flows push changes instantly but need inbound network access and retry handling. Polling every one to five minutes is simpler to secure and acceptable for most incidents. Whichever you choose, make sure the integration catches up after downtime by querying from the last successful sync time, not from "now".
Choosing how to build it
The rules in this guide apply whichever tool you use. What changes is how much you build yourself.
- ServiceNow IntegrationHub Jira spoke: provides actions for creating and updating issues and handling attachments, but you design the flows, the priority mapping and the comment filtering in Flow Designer. Two-way updates need webhook setup on the Jira side.
- No-code integration platforms such as ZigiOps: ZigiOps ships with templates for ServiceNow incidents and Jira issues, tracks transferred attachments, applies conditional mapping for priority and filters comments by author or type, all in a guided UI with no scripts on either side. ZigiOps does not store transferred data. Script-based or app-based alternatives include Exalate, Getint and Unito.
- Custom REST integration: full control, but you write and maintain the duplicate tracking, retry logic, loop prevention and formatting conversion yourself.
Testing checklist
Test in sub-production instances of both systems with these cases before going live.
- Attach three files with the same name to an incident and confirm three distinct files arrive in Jira, once each.
- Attach a file larger than the lower platform limit and confirm it is skipped with a note, and that the rest of the update succeeds.
- Create incidents for every impact and urgency combination and confirm each Jira priority matches the table.
- Change priority in Jira and confirm the agreed behaviour: either nothing happens, or impact and urgency change to the reverse mapping.
- Add a work note and confirm it appears in Jira as an internal comment, not a public one.
- Add a customer-visible comment in ServiceNow and confirm it arrives in Jira as internal, with the prefix.
- Add a Jira comment and confirm it arrives as a work note, not as an additional comment, and does not trigger a customer email.
- Stop the integration for an hour, make changes on both sides, restart it and confirm everything catches up without duplicates.
Troubleshooting common problems
| Symptom | Likely cause | Fix |
|---|---|---|
| Same attachment appears many times in Jira | No record of transferred attachment IDs; integration resends all files on each update | Store source attachment IDs or send only attachments created after the last sync |
| All Jira issues are created as Medium | Priority mapped only on create with a default value, or value names do not match the project's scheme | Map on create and update, check the exact priority names in the target scheme |
| Customers receive engineers' comments by email | Jira comments mapped to ServiceNow additional comments | Map Jira comments to work_notes by default |
| Comments bounce back and forth | No filter on comments created by the integration user | Exclude the integration user as an author in both directions |
Frequently asked questions
How do I sync attachments between ServiceNow and Jira without duplicates?
Store the source attachment identifier (the sys_attachment sys_id in ServiceNow, the attachment ID in Jira) when a file is transferred, and only send files whose identifiers have not been sent before. Alternatively, send only attachments created after the last successful sync time.
How do I sync comments between Jira and ServiceNow?
Read journal entries from the comments and work_notes fields in ServiceNow and the comment stream in Jira, then map each type according to visibility. Keep work_notes internal in Jira, map Jira comments to work_notes by default, and filter out comments created by the integration user to prevent loops.
Can I map ServiceNow priority to Jira priority in both directions?
Yes, but because ServiceNow calculates priority from impact and urgency, the reverse direction must set impact and urgency, not priority. Define one impact and urgency pair for each Jira priority and document it.
Can ZigiOps sync attachments, priorities and comments between Jira and ServiceNow in both directions?
Yes. ZigiOps synchronizes comments, work notes and attachments as related records in both directions, and sets Jira priority from ServiceNow impact and urgency through conditional mapping. Everything is configured in a no-code UI.
Should work notes sync to Jira Service Management as public comments?
No. Work notes are internal by design. Map them to internal comments in Jira Service Management so they never appear on the customer portal.
Key takeaways
- Attachments, priorities and comments break more often than other fields because they are lists, they are modelled differently on each side, and they carry risk.
- Prevent duplicate attachments by tracking source IDs, and filter files by size and type using the lower of the two platform limits.
- Translate ServiceNow's impact and urgency matrix to Jira priority with an explicit table, and decide which system owns priority.
- Keep work_notes internal, route Jira comments to work_notes by default, and filter out the integration user to stop loops.
- ZigiOps lets you configure attachment tracking, conditional priority mapping and comment filtering without code, and it does not store the data it transfers.
- Test duplicate, oversize, reverse-priority and visibility cases in sub-production before going live, whichever tool you use.