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
- Head to the Exalate app.
- You can sign in with Google (SSO) using a company email or register a new account directly.
- Click Create an account and fill in your business email, first name, last name, and a strong password.
-
Confirm your password and click Create an account to continue.

- If signing up with your Google profile, you'll go through Google authentication to verify your account.
- Log in to Exalate using your email and password.
Create a Connection Between Jira and Salesforce
- Sign in to your account.
-
Click Add Connections > Create New Connection.

- The connection wizard walks you through several steps.
- To connect System A (Jira):
- Drop in the system URL [https://example.atlassian.net].
- The console runs an automatic status check.
- If the system is up and running, you'll see a confirmation and skip the auth step.

- If the system is being authenticated for the first time, you'll see the Jira Cloud OAuth option.
- Run through the Jira Cloud OAuth flow.
- 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.

Note: You can also enable the Forge extension for advanced Jira use cases, like comment impersonation. Check the details here.
- Click Next to move on to System B (Salesforce), repeat the steps from System A:
- Enter the Salesforce instance URL.
- Wait for automatic system type detection.

- Provide your authentication credentials. Salesforce uses an API token.
- Click Check Authentication to confirm.
- Click Next to keep going.
- 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.
- Add a short description that reminds you what this connection is for. For example, "Sync Closed Won opportunities to deliver work items in Jira."
- Click Next to review the configuration.
- Double-check the connection name and description on the summary screen.
- Click Create Connection to kick off the setup.
- Exalate registers your systems and creates the connection automatically. You'll see the progress update live as the steps are completed.

- Once it wraps up, click on Continue to Configuration to proceed.
- After your connection is created, click Build & Continue to complete the configuration.
Note: If a system doesn't have the concept of a project, this modal won't show up.
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.
- Click Publish & quick sync.
- Under "Item sync monitor," type the work item key (or Salesforce case number) and click Sync Now.
-
To pair an existing item on each side, click Link with existing.

- When the sync wraps up, both items appear in a new window so you can compare the changes.
- For deeper customization, use Edit & Test Sync:
- Open your console and find the connection in the Connections list.
- Click the connection name (or the Edit button) to open its configuration page.
- On the connection configuration page, you'll see the current sync rules.
- To change them, click on + New Version to create a new draft version. This way, you don't accidentally edit the active configuration.

- Hit Edit Script 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.
- 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.

- Every version of a connection lives under the Version dropdown beneath the connection name.
- 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
- Open your connection.
- Click + New version (or open the latest draft).
-
Click Edit to launch the script editor.

- In the Aida input field, describe what you want in plain English.
- Click send (or press Enter).
- Aida starts drafting your script. Look over the suggestions. Green lines are additions, red lines are removals.

- 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".
Note: Aida saves time, but always read the generated code before pushing it live.
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.
- Open the connection, then click on Edit Script >Start Test Run to validate.
- Click on Select Items to pick the items you want to test (multiple selections work). Click "Start Test Run" to preview how the configuration handles them.
-
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.
- 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.
-
Click "+ Add trigger" to set up a new one.
-
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
- Jira Query Language (JQL):
- Toggle triggers on to activate them, then publish to save your changes. Click Save Trigger to save changes and publish the trigger.

Troubleshoot with Aida
- Navigate to the “Troubleshooting” tab in your workspace.
- 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.
-
For deeper investigation, click “Error Details” to view the impact level, stack trace, error type, and occurrence date.

- 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:
"When a Salesforce Opportunity reaches the Closed Won stage, create a parent Epic in the DEL project with the account name as the summary, the contract value in a custom field called 'Deal Value', and the close date as the due date. Set the assignee to the project lead." |
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:
|
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:
"In the Jira incoming sync, map Salesforce statuses to Jira: 'New' becomes 'To Do', 'Working' becomes 'In Progress', and 'Escalated' becomes 'Done'. Also sync the SF Contact custom field from Salesforce into the matching Jira custom field." |
The generated incoming sync on the Jira side:
|
On the Salesforce side, the incoming script flips the mapping so changes from Jira write back correctly:
|
This setup is what powers most account-tier custom field syncs, including ones that drive automation downstream in Salesforce based on Jira status.
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:
|
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:
The Salesforce outgoing sync flattens Chatter threads so each reply shows up as a Jira comment with the author's name prepended:
|
|
On the Salesforce incoming side, a commentMap translates the email addresses back to Salesforce User IDs so mentions tag the right person. The full implementation handles HTML stripping, threaded reply expansion, and user mapping in one pass.
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.
Note: The code snippets here are illustrative and may need adjustments for your specific environment. If something doesn't behave as expected, reach out for support.
If you want to discuss your specific setup, book a demo with our integration engineers.
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.












