Use Case: How to auto-populate Salesforce data in Jira Service Desk Tickets

by High Order Solutions


The customer uses two different systems for sales and project work. Both are in the Cloud and both teams need to access customer information to do their jobs. Oh, and they both want the ability to add or edit information without forcing the other team to use the other team’s tool.

What tools are we talking about you may ask?  Of course, we’re talking about Salesforce and Jira.

First, their sales people like to use Salesforce for Contact Management and Customer Relationship Management as well as the “source of truth” for all incoming support tickets. Why? Because they also used Salesforce to manage work and incoming support requests for billing purposes. The second problem, those that work on those tickets in Development like to manage their work using Jira Software for development and Jira Service Desk for customer support.


For this small problem we’re only talking about auto-populating Salesforce customer data on to the support tickets used by the Dev group. Whether or not an eventual single product solution happens isn’t important right now, but it is something we needed to consider going forward.


There are several in the Atlassian Marketplace but my customer wants to balance customizability with cost so we went with an add-on called Connector for Salesforce and Jira.  It only costs $10 a month for 10 users then $2.20 per user for 11-200 users and includes the following functionality:

Why you’ll love Connector

  • Utilize the tool in as little as 1 hour!
  • No more context-switching. Work in the platform you love
  • Reduce error-prone, time-wasting manual entry
  • Automation reduces friction, improves productivity


  • Improve customer acquisition
  • Enhance retention strategy
  • Better customer experience
  • Increase cross-team collaboration
  • License consolidation cost savings


  • Bi-directional auto synchronization – This was important to both teams (does not apply to customer field/tab in JSM projects)**
  • Automated workflows – This was important to management
  • Aggregated comments
  • Many-to-many associations
  • Salesforce Lightning enabled
  • Quick View Panel and reporting features
  • Jira cascading select lists
  • Salesforce dependent picklists


Like most, this problem is only a small part of a bigger problem and a bigger solution that will require careful planning and execution. Any correct solution must be both modular and scalable so it works independently of anything else going on while not conflicting with other integrations or migrations that might come later.

In addition to these high level challenges, the following cropped up along the way:

  • In order to create the SF to Jira association you must be a licensed Jira user with Edit Issue permissions, so Read-only users can’t set this add-on up. Probably best to let an experienced project admin or your Atlassian admin do it.
  • Your Jira administrator must have already bound the Jira project to the SF connection before attempting the SF to Jira association
  • Any and all custom field types being used must be of a similar type in each product before they can be mapped, again something only an experienced Atlassian admin could make sure is setup correctly
  • And lastly, a possibly limitation, each Jira issue can only be associated with a maximum of 300 Salesforce records due to the storage limitations imposed by Jira. Although rare, this can occur for your large customers with many contacts.

Take-Aways & Lessons Learned:

In the end, an efficient solution can always be found as long as you don’t sacrifice best-practices and the customer isn’t afraid of a little change. As noted before the right solution(s) are those that are easily scalable and that don’t add unnecessary complexity for the sake of the current processes.  If either or both are the case, then it’s not the right solution. And most likely not the right process.