Jira and Salesforce Integration

Sales, support, and development teams rarely work in the same tool. Sales lives in Salesforce, support tracks customer cases there too, while engineering builds and ships from Jira. When those teams need to hand work back and forth, the gap between platforms turns into manual updates, missed context, and stalled projects.

A Jira Salesforce integration keeps work item data, case details, opportunity stages, and comments flowing between both systems without anyone copying fields across tabs.

Exalate handles this with a bidirectional sync that's compatible with Jira Service Management, Jira Software, Jira Product Discovery, Jira Work Management, and Salesforce Cases, Opportunities, Accounts, Contacts, and custom objects. 

It also supports cloud, on-premise, and Docker deployments, which matters when one side has data residency requirements that the other doesn't.

Exalate Ramp-up and Configuration Steps

Here's a quick walkthrough for setting up your Jira Salesforce connection from scratch.

Create an Account or Log In to an Existing Account

1. Head to the Exalate app.
2. You can sign in with Google (SSO) using a company email or register a new account directly.
3. Click Create an account and fill in your business email, first name, last name, and a strong password.
4. Confirm your password and click Create an account to continue.
   
5. Verify Your Email: Open the verification email from New Exalate. Note: The verification link is valid for 2 hours.
6. Click the link in the email to finish setting up your account.
7. Log in to New Exalate using your email and password. 

Create a Connection Between Jira and Salesforce

1. Sign in to your account.
2. Click Add Connections > Create New Connection.
   
3. The connection wizard walks you through several steps.
4. To connect System A (Jira):
   1. Drop in the system URL [https://example.atlassian.net].
   2. The console runs an automatic status check.
   3. If the system is already in your workspace, you'll see a confirmation and skip the auth step.
   4. If it's registered but lives in a different workspace, the message reads "System registered, but not yet part of Workspace."
   5. If it's a brand-new system, the auth fields show up automatically.
   6. Run through the Jira Cloud OAuth flow.
   7. Click Check Authentication and wait for the validation to finish. If you have access to multiple Jira sites, pick the one for this connection. The Next button activates once authentication succeeds.
      
5. Click Next to move on to System B (Salesforce), repeat the steps from System A:
   1. Enter the Salesforce instance URL.
   2. Wait for automatic system type detection.
   3. Provide your authentication credentials. Salesforce uses an API token.
   4. Click Check Authentication to confirm.
   5. Click Next to keep going.
6. Give your connection a unique, descriptive name like "Jira-SF-RevenueOps". If the name clashes with an existing one, you'll be prompted to pick another.
   
7. Add a short description that reminds you what this connection is for. For example, "Sync Closed Won opportunities to deliver work items in Jira."
8. Click Next to review the configuration.
9. Double-check the connection name and description on the summary screen.
10. Click Create Connection to kick off the setup.
11. Exalate registers your systems and creates the connection automatically. You'll see the progress update live as the steps are completed.
    
12. When everything finishes, a success message appears and the connection status flips to "Ready to configure."
13. Once the connection exists, choose which projects to sync between the systems.

Configure Your Bidirectional Jira to Salesforce Connection

You have two paths from here: Quick Sync and Edit & Test.

Quick Sync is for syncing a single item between Jira and Salesforce so you can confirm the connection works before doing anything else.

1. Under "Item sync monitor," type the work item key (or Salesforce case number) and click Sync Now.
2. To pair an existing item on each side, click Link with existing.
   
3. When the sync wraps up, both items appear in a new window so you can compare the changes.
4. For deeper customization, use Edit & Test Sync:
   1. Open your console and find the connection in the Connections list.
   2. Click the connection name (or the Edit button) to open its configuration page.
   3. The page loads with the current sync rules visible.
   4. Don't edit the active config directly. Instead, create a new version or click Open latest draft.
      
5. Hit Edit to launch the editor:
   • Update sync rules using Aida (the outgoing script controls what data leaves Jira, and the incoming script defines how Salesforce data lands on the Jira side).
   • Click Save Script to keep the version, or Start Test Run to validate it.
   • Click Publish Version when you're ready to make the config live.
6. To work in the opposite direction, click Switch Direction (say you want to edit the Jira incoming and Salesforce outgoing). This activates a new version (or draft) for that direction, and you'll review and publish it the same way.
   
7. Every version of a connection lives under the Version dropdown beneath the connection name.
8. Versions can be:
   • Active: The published configuration currently in use.
   • Draft: An editable copy of the Active version.
   • Archived: The previous Active version is archived when you publish a new one. Click Restore version to bring it back.

AI-Assisted Configuration with Aida

1. Open your connection.
2. Click Add new version (or open the latest draft).
3. Click Edit to launch the script editor.
   
4. In the Aida input field, describe what you want in plain English.
5. Click send (or press Enter).
6. Aida starts drafting your script. Look over the suggestions. Green lines are additions, red lines are removals.
7. Click Insert to apply or Discard to ignore.
   • For Outgoing scripts: Describe what should leave the system. For example, "Don't sync internal-only comments and send opportunities tagged for delivery."
   • For Incoming scripts: Describe how the data should be applied. For example, "Map Salesforce statuses to Jira workflow states".

Test Run: Validate Before Production

Once your sync scripts are ready, click "Start Test Run" to check them against real data without affecting anything live.

1. Pick the items you want to test (multiple selections work). Click "Start Test Run" to preview how the configuration handles them.
2. Look through the incoming and outgoing replicas for each test item. Confirm the field mappings look right. If something's off, jump back, tweak, and test again.
3. Only deploy when you're sure things are clean. Click "Publish Version" to roll the updated config out to live syncs.

Automate Jira Salesforce Integration Using Triggers

Triggers decide which items kick off a sync based on conditions you set.

1. Click "+ Add trigger" to set up a new one.
2. Add the conditions using each platform's query syntax:
   • Jira Query Language (JQL): project = ITDEMO AND priority in (High, Medium).
   • Salesforce Object Query Language (SOQL):  StageName = 'Closed Won' AND Amount > 50000

Toggle triggers on to activate them, then publish to save your changes.

Troubleshoot with Aida

1. Navigate to the “Troubleshooting” tab in your workspace.
2. Hover over any error and click the Aida icon for immediate analysis. Aida shows affected systems, connections, and work items, plus a brief explanation of the error.
3. For deeper investigation, click “Error Details” to view the impact level, stack trace, error type, and occurrence date.
   
4. Use “View Full Analysis” for complete context. Once you’ve resolved the issue, click “Resolve” to clear the error.

Your integration is now active. Synchronization runs automatically based on your configured sync rules and triggers.

Advanced Jira and Salesforce Integration Use Cases (Using Aida)

Exalate's scripting engine is what makes the AI-powered Jira Salesforce integration work for non-trivial setups. It also provides Script Helpers that take a lot of the heavy lifting out of writing scripts from scratch.

Here are some of the most common use cases teams build with it.

Use Case 1: Auto-Create Jira Work Items When Salesforce Opportunities Hit Specific Stages

A sales team closes a deal in Salesforce, but the delivery team only finds out when someone manually creates work items in Jira. For RFP teams, the cost is even higher. They might run daily Salesforce reports for new opportunities, then copy the data into Jira to create campaign-level tickets and downstream tasks. 

The fix is letting Exalate create Jira work items automatically when an Opportunity reaches stages like "Proposal" or "Closed Won." 

Each side controls its own rules, so the Salesforce admin defines what opportunity data leaves Salesforce, and the Jira admin defines how that data lands as a project, work item type, assignee, and custom fields.

A sample prompt to Aida looks like this:

Aida generates the script for the Salesforce outgoing and Jira incoming sync, and you can refine the prompt to lock in the exact behavior. Status changes in Jira flow back to Salesforce, so account executives see real-time delivery progress without pinging the project manager.

Use Case 2: Route Salesforce Cases to Different Jira Work Item Types

Salesforce Cases come as support requests, bugs, and feature requests. Dropping all of them into one Jira queue means engineers waste time triaging instead of working.

With Exalate, you can route each case to a different Jira work item type based on Case Type, Priority, or any custom field on the case. Support cases become Support work items, technical issues become Bugs, and enhancement requests become Feature Requests. 

Here's a sample script for the Jira incoming sync:

if (firstSync) { def caseType = replica.customFields."Case_Type__c"?.value def typeMap = ["Bug" : "Bug", "Feature Request" : "Story", "Support" : "Task"] issue.projectKey = "SUP" issue.typeName = nodeHelper.getIssueType(typeMap[caseType] ?: "Task", issue.projectKey)?.name }

You can extend the logic to escalate a support case to a bug when specific keywords appear in the description, or push critical bugs to the engineering sprint board with "Highest" priority. The conditional logic runs on Exalate's Groovy engine, so edge cases are handled in code rather than worked around manually.

Use Case 3: Sync Statuses and Custom Fields Between Jira and Salesforce

Selecting an account name in a Jira drop-down and having that update the corresponding Salesforce Case is a common ask. Status changes are the other half of the same story. When an engineer moves a Jira work item to "Done," the Salesforce Case should reflect "Resolved" without anyone updating it by hand.

A prompt to Aida might look like this:

The generated incoming sync on the Jira side:

def statusMapping = ["New" : "To Do", "Working" : "In Progress", "Escalated" : "Done"]def remoteStatusName = replica.Status.valueissue.setStatus(statusMapping[remoteStatusName] ?: remoteStatusName)replica.customFields."SF Contact" = issue.customFields."SF Contact"

def statusMap = ["To Do" : "New", "In Progress" : "Working", "Done" : "Escalated"]def remoteStatusName = replica.status.nameentity.Status = statusMap[remoteStatusName] ?: remoteStatusNameentity."Jira_custom_field__c" = replica.customFields."SF Contact".value.value

Use Case 4: Sync a Single Salesforce Case to Multiple Jira Projects

A Salesforce Case sometimes needs eyes from more than one team. A backend engineering squad might own part of a fix while QA owns testing, and each works in a separate Jira project. Manually creating duplicates in both projects is the kind of work that gets dropped on busy days.

Exalate handles this through conditional routing in the Jira incoming sync. A custom field on the Salesforce Case (like a product line picklist or a "Sync Over" checkbox) determines which Jira project receives the work item.

Here's a sample script for the Jira incoming sync:

if (firstSync) { if(replica.sync_over__c == true){ issue.projectKey = "DEMO" } else { issue.projectKey = "SMP" } issue.typeName = nodeHelper.getIssueType(replica.type?.name, issue.projectKey)?.name ?: "Task"}

Use Case 5: Sync Comment Threads and User Mentions Between Jira and Salesforce

Sales reps and support agents leave comments on Salesforce Cases, while engineers leave comments on Jira work items. When those threads don't sync, both teams end up reading half-conversations and asking each other for context.

The trick is that Salesforce uses HTML for comments and supports threaded replies through chatter feeds, while Jira uses Wiki Markup and has a flat comment list. Mentions don't translate either, since each platform has its own user IDs.

But Exalate has a workaround. The Jira outgoing sync extracts mentions and replaces them with the user's email so Salesforce has something to match on:

replica.comments = issue.comments.collect { comment -> def matcher = comment.body =~ /[~accountid:([\w:-]+)]/ def newCommentBody = comment.body matcher.each { target = nodeHelper.getUser(it[1])?.email newCommentBody = newCommentBody.replace(it[0], target) } comment.body = newCommentBody comment}

replica.comments = entity.comments.inject([]) { result, comment -> def res = httpClient.get("/services/data/v54.0/query/?q=SELECT+Name+from+User+where+id=%27${comment.author.key}%27") comment.body = nodeHelper.stripHtml(res.records.Name[0] + " commented: " + comment.body) result += comment def feedResponse = httpClient.getResponse("/services/data/v54.0/chatter/feed-elements/${comment.idStr}") feedResponse.body.capabilities.comments.page.items.collect { res = httpClient.get("/services/data/v54.0/query/?q=SELECT+Name+from+User+where+id=%27${it.user.id}%27") def c = new com.exalate.basic.domain.hubobject.v1.BasicHubComment() c.body = res.records.Name[0] + " commented: " + it.body.text c.id = it.id result += c } result}

Use Case 6: MSP Multi-Tenant Support Sync With Restricted Access

Managed service providers run a single Jira (or Jira Service Management) instance internally, but their clients use whatever they want. One client might be on Salesforce, another on Zendesk, another on Freshdesk. 

Exalate handles this by treating every connection as its own scoped entity. The MSP runs separate connections for each client environment, and each connection has its own sync rules, field mappings, and trigger conditions. 

A case from Client A's Salesforce lands in the MSP's Jira queue with Client A's account context. Internal triage notes stay in Jira, and only resolution updates flow back to Client A. Nothing leaks between client connections because they're configured independently.

This is also where the cross-company autonomy matters most. The MSP can update its sync rules without coordinating with every client, and a client can update theirs without breaking the MSP's setup.

Supported Jira and Salesforce Entities

Take a look at the full list of supported Salesforce entities and the full list of supported Jira Cloud and On-premise entities.

Here's a sample mapping between Salesforce Cases and Jira work items:

Salesforce Case <> Jira work item

• Subject ↔ summary

• Description ↔ description

• Priority ↔ priority

• Status ↔ status

• Contact ↔ reporter

• Comments ↔ comments

• Attachments ↔ attachments

• Tags / Topics ↔ labels

• custom fields ↔ custom fields

• third-party plugin fields

• any field exposed via REST APIs

Salesforce Opportunities, Accounts, Contacts, and custom objects can also be synced to Jira work items, Epics, or custom work item types.

Other Resources

• Start a free trial with Exalate, or hop on a call with our integration engineers to talk through your use case.

• Still on Exalate Classic? Browse its documentation here. You can also read up on the differences between Exalate Classic and New Exalate.

• Head to our Trust Center for the security details.

• Got configuration questions? The Exalate Community is where to ask them.

• Join our Sync Room Webinar series for answers to integration pain points, AI trends in the integration space, and more.