# Salesforce Jira integration

*Salesforce → Jira*

**In short:** A Salesforce to Jira integration turns an escalated Case or a deal blocked on a missing feature into a Jira issue carrying the account, tier, and contract value engineering needs to prioritise, then pushes transitions, fix versions, and resolutions back onto every linked Salesforce record. Done properly it is not a field mirror: it joins on immutable record and issue IDs, drives Jira through legal workflow transitions instead of writing statuses, respects both API budgets, and never reacts to its own events.

## What a Salesforce to Jira integration actually does

Salesforce holds the commercial truth: the Account, the renewal date, the Case a support agent opened this morning, the Opportunity stalled for six weeks on a missing feature. Jira holds the work: a bug in a sprint, an epic on a roadmap, a fix version with a release date attached.

Between them sits a handover most companies still do by hand. An agent copies a Case into Jira and pastes the issue key back into a text field. An engineer looks at a bug with no idea whether it affects one trial account or three of the largest contracts in the book. A CSM asks in Slack, for the fourth time, whether PROD-4172 shipped.

A Salesforce to Jira integration closes that loop both ways. Escalated Cases and blocked Opportunities become Jira issues carrying the account context engineering needs to prioritise, and transitions, fix versions, and resolutions travel back onto every linked Salesforce record automatically.

## What data moves

| Salesforce object / event | Becomes / updates in Jira | Notes |
| --- | --- | --- |
| Case escalated (status, Escalated flag, or a trigger field) | New issue, or link to an existing one | Project and issue type routed by product, record type, or queue |
| Case Subject and Description | Issue summary and description | Salesforce rich text converted to Atlassian Document Format |
| Case Priority / Severity | Jira priority | Mapped to that project's priority scheme, never assumed 1:1 |
| Case Comment (published vs internal) | Issue comment | Internal comments stay restricted, never customer-visible |
| Account, tier, ARR, renewal date | Jira custom fields on the issue | Gives engineering the commercial weight behind a defect |
| Opportunity blocked on a product gap | Feature request issue, or link to an existing epic | Multi-currency orgs need an explicitly converted amount |
| Files (ContentVersion / ContentDocumentLink) | Issue attachments | Size caps differ; large logs stay as a link, not a copy |
| **Jira event** | **Updates in Salesforce** | **Direction reverses** |
| Workflow transition | Case status or a dedicated engineering status field | Per-project workflows mapped onto one Salesforce picklist |
| Fix version assigned / released | Field update, Chatter post to the Case owner | Tells Support and Sales when the customer can be told |
| Issue resolution (Done / Won't Do) | Case update, optional closure, notification | One fix fans out to every linked Case |

The exact routing rules, field mapping, and which transitions matter to a support agent are agreed once during scoping and encoded in the pipeline. After that, nobody re-maps them by hand.

## The details that break naive syncs

- **Join on IDs, not on the readable ones.** A Jira issue key like PROD-4172 changes the moment an issue moves to another project; the numeric issue ID does not. Store both and match on the ID. On the Salesforce side, join on the 18-character record ID rather than CaseNumber, which is only meaningful inside one org and repeats across sandboxes.
- **Status is a transition, not a field.** A Jira status cannot be written directly. It requires a transition that is legal from the issue's current status in that project's workflow, and company-managed and team-managed projects expose those differently. A connector that treats status as writable either fails loudly or drifts silently.
- **Custom field IDs are per instance.** Salesforce fields have stable API names; Jira's are `customfield_10042` and carry different numbers in sandbox and production. Mapping by label breaks the day someone renames a field.
- **API budgets and partial failures.** Salesforce enforces an org-wide 24-hour request allowance a bulk resync can burn through before lunch, and Jira Cloud answers cost-based rate limiting with 429 and Retry-After. In a batch of forty escalations, three will also hit a required field on the Jira create screen that Salesforce has no equivalent for: those three retry, the rest do not, and no Case is left pointing at an issue that was never created.
- **Delta detection.** Delta queries should key on SystemModstamp so system-driven updates are not missed, and the replay window on Change Data Capture is finite, so a longer outage needs a reconciliation query. Jira's `updated >= -15m` in JQL has minute granularity in the account's timezone, so polling windows need overlap plus deduplication.
- **Ordering and echo loops.** Jira webhooks are at-least-once and unordered, so two edits seconds apart can arrive backwards, and every write the pipeline makes into Jira fires a webhook that would write back into Salesforce. Both need a correlation key, an integration user whose own events are suppressed, and a check against last known state.
- **Visibility and SLA clocks.** Internal Case Comments must not surface as customer-visible replies in Jira Service Management, and fields hidden by Salesforce field-level security must not reappear on an issue half the company can browse; issue security levels are the control. Salesforce Entitlements and Jira Service Management SLAs are also independent timers, so "waiting on engineering" has to be an agreed state on both sides.

## How we build and run it

We treat this as a pipeline, not a two-way field mirror. Case, Comment, and Opportunity changes reach it through Platform Events or Change Data Capture where the org is set up for that, and through SystemModstamp-based polling where it is not. Each change is validated, routed to the agreed Jira project and issue type, mapped onto that project's priority scheme and custom fields, converted to Atlassian Document Format, and written through the Jira REST API using legal workflow transitions. Jira webhooks drive the reverse leg and write a remote issue link back to the Salesforce record, so the trail runs both ways.

The pipeline is idempotent. Every synced record carries a stable correlation key, so a retry, a replay, or a webhook the pipeline itself triggered never produces a duplicate issue, a duplicate comment, or an endless echo. It runs on cloud-native, fully EU-hosted AWS infrastructure, so Case, Account, and contact data never leaves the EU, which keeps your DPA / AVV and GDPR position clean.

Then we keep it running. Monitoring, alerting, incident response, and watching for Salesforce and Atlassian API changes are our responsibility under contract, scoped at a fixed price with a named owner and an SLA.

## When this integration is worth building

If one support team escalates a handful of bugs a month into a single standard Jira project, a marketplace connector or even a manual link on the Case is genuinely fine, and we will tell you that. A managed pipeline earns its place when several Jira projects with different workflows are in play, when prioritisation depends on account tier and contract value sitting on the issue, when one fix has to close dozens of Cases, when comment or field visibility cannot fail even once, when you run Jira Data Center or a mix of Cloud and self-hosted, or when support and account teams spend real hours every week chasing a status a pipeline should already have delivered.

## Frequently asked questions

### We already have a marketplace connector between Salesforce and Jira. Why build anything?

Marketplace connectors do a competent job of one Salesforce org talking to one standard Jira project with a near-identical field set. They get thin once you run several Jira projects with different workflows, need routing rules based on product or record type, want many Cases pointing at one bug, or care that a specific field never crosses. We build the mapping and the operating rules your teams actually work by, and then we run it under contract rather than handing you an admin screen.

### Can engineering see how much revenue is behind a bug?

Yes, and it is usually the strongest argument for the integration. We write account name, contract tier, renewal date, and ARR or open Opportunity value onto Jira custom fields when the issue is created, and refresh them as the Salesforce record changes. Product and engineering then prioritise against real commercial weight instead of asking Sales in Slack. Multi-currency orgs need an explicit converted amount, since Jira has no currency-aware field type.

### How do you stop internal comments and hidden fields reaching a customer?

By mapping visibility deliberately rather than trusting a default. A Case Comment marked internal never becomes a customer-visible Jira Service Management reply, and fields your integration user cannot see under Salesforce field-level security never reach an issue. On the Jira side we use issue security levels and comment restrictions as part of the mapping, agreed with you during scoping and tested before go-live.

### What happens when twenty accounts report the same bug?

They all link to one Jira issue. Opening twenty duplicates buries engineering and destroys the prioritisation signal. When that issue is resolved or assigned a fix version, the pipeline fans the update back out to every linked Case and, where you want it, notifies each Case owner. A one Case to one issue connector cannot express that relationship.

### Who operates it after go-live, and what about Salesforce and Atlassian API changes?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, with alerting, incident response, and a named owner under an SLA. Salesforce ships three seasonal releases a year and retires old API versions on a published schedule; Atlassian deprecates Jira Cloud endpoints on its own. Tracking both and adapting the pipeline before anything breaks is our contractual obligation, not a ticket your admin discovers after a failed sync.

## Related integrations

- [Freshdesk ↔ Jira](https://seamless.engineering/integrations/freshdesk-jira/): Freshdesk Jira integration
- [Freshservice ↔ Jira](https://seamless.engineering/integrations/freshservice-jira/): Freshservice Jira integration
- [Intercom ↔ Salesforce](https://seamless.engineering/integrations/intercom-salesforce/): Intercom Salesforce integration
- [Jira ↔ Slack](https://seamless.engineering/integrations/jira-slack/): Jira Slack integration
- [ServiceNow ↔ Jira](https://seamless.engineering/integrations/servicenow-jira/): ServiceNow Jira integration
- [ServiceNow ↔ Salesforce](https://seamless.engineering/integrations/servicenow-salesforce/): ServiceNow Salesforce integration

## Browse by system

- [All Salesforce integrations](https://seamless.engineering/integrations/salesforce/)
- [All Jira integrations](https://seamless.engineering/integrations/jira/)
- [Salesforce API changelog](https://seamless.engineering/api-changelog/salesforce/): No breaking changes or deprecations in the last 90 days
- [Jira Cloud API changelog](https://seamless.engineering/api-changelog/jira/): 2 breaking changes and 11 deprecations in the last 90 days

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact