Salesforce often involves multiple objects that have an association between them. For instance, an Opportunity can have an Account or Product association, or a Case can have a linked Account or Contact, or there can be a completely new custom object.
And then I have often come across requests where these related objects in Salesforce need to be synced over to Jira for better visibility to different teams.
Hence, this post to help you understand how this can be achieved using a 3rd party integration solution like Exalate.
We have a Case object that has a Contact and Account linked to it and that needs to be presented on the Jira side.
Exalate is a bi-directional synchronization solution that integrates different platforms like Jira, Salesforce, Azure DevOps, ServiceNow, Zendesk, GitHub and more. The above use case can be implemented using the Exalate API. With a built-in Groovy-based scripting engine, you have the necessary capabilities to implement almost any use case.
As an Exalate administrator you can configure both the incoming and outgoing processors on each side independently. These processors on both Jira and Salesforce filter what information must be sent and received.
Search for the Exalate app on both these platforms and start following the installation wizard, which is pretty straightforward.
Note: To know about how it can be done on Jira on-premise, have a look at this doc.
Then a connection must be established between them. There are 2 types of connections that are supported: Basic mode and Script mode.
The Basic mode is for syncing basic entities like summary, description, comments, attachments and issue types in Jira and Cases in Salesforce. As you can't configure it, it is suitable for simple integration cases, but you can use it for free.
The Script mode connection provides independent control on each side. It consists of Groovy scripts that help configure the incoming and outgoing information. It can be done by editing the Sync rules.
Keeping in mind the advanced configuration of this use case, it is recommended we use the Script mode connection.
Once the connection has been set up we start configuring it. Both the incoming and outgoing scripts need to be configured at either end. ‘Outgoing sync’ at the Jira end decides what information goes out from Jira to Salesforce and ‘Incoming sync’ at Jira keeps track of how to receive information coming from Salesforce. These syncs are present at the Salesforce end too.
As seen in the script below, all the information (sent or received) is through something called ‘replica’. This ‘replica’ acts like a payload or message being sent as a part of a sync transaction. It can contain issue, Case or any other information that needs to be passed between the two platforms.
Let us have a look at the ‘Incoming’ and ‘Outgoing’ syncs that need to be configured at Jira and Salesforce by following the steps of this use case along the way.
Since there is no additional information apart from the defaults that need to be sent from Jira to Salesforce, we keep it as it is.
You can find the entire snippet here.
Here, you will check if the entity from the replica is ‘Case’, if it is and it’s the first sync, then you create a ‘Task’ in Jira.
And then we call: syncHelper.syncBackAfterProcessing().
This is a helper method the Exalate API provides. When it’s the first sync, this method syncs back to Jira, so there is an incoming sync for Jira to fetch the Contact and Account information from Salesforce.
Note: You can also have a look at the other helper methods provided by the Exalate API.
Right now let’s go to the other end (Salesforce incoming) to be inline with the steps of our use case. We will have a look at the remaining code in the ‘Incoming sync’ of Jira in step 4 again.
In Salesforce, if it is the first sync then a Case is created. Do remember that this is completely customizable, you can create any other entity if you want.
Line 6: If the entity type is Case, then proceed with fetching the Account and Contact information
Line 10: The value of the syncRequest.remoteSyncEventNumber is checked to see if it’s equal to 1. If it is, then it ensures that the code that goes next is executed only once and not on every subsequent sync.
Line 12: Checks if there is some Account information to be fetched (i.e it’s not null).
Line 16: Executes the scheduleConnectEvent method which connects the linked Account from Salesforce with the Jira issue already synced with the Case, and doesn’t create a new one. It uses the replica.key from the Jira side to form this link. This key is already received in the syncBack transaction.
The same set of code applies to fetching the Contact details as well.
Now coming back to the incoming sync on Jira, it’s time we display the fetched Account and Contact details.
As seen, the details are displayed in custom fields called ‘SF Contact’ and ‘SF Account’.
Line 26, 39: Check if the type of entity received from Salesforce is Account or Contact and depending on it, the details are displayed further.
Line 36, 37: Name, Title and Email of the Contact are displayed.
Line 42,43: Name and Description of the Account are displayed.
Additional fields from both these Salesforce records or some other Salesforce record in itself can also be displayed this way.
Note the ‘|’ and ‘||’ used here are just to display the data in the form of tables. It has nothing to do with Exalate.
Let us quickly see how all this looks into action.
We start by creating a Case in Salesforce and assign a Contact and Account to it.
Then sync it over to Jira (either manually or through triggers).
In a short while, under the issue created in Jira you can see the Account and Contact related information being displayed under the 2 custom fields in Jira in the form of a table.
Open the Exalate panel on the issue view and you can see the Account, Case and Contact sync status and also their respective remote links.
You can try making some changes to either the Account or the Contact in Salesforce and see those being reflected in Jira.
We saw how multiple-related objects within Salesforce can be synced over to Jira or even some other platforms like Azure DevOps, ServiceNow, GitHub or Zendesk. This was possible using an integration solution called Exalate that uses Groovy based scripts to implement even the most advanced or complex use cases.
This month the spotlight is on AppLiger. We caught up with Pavel Pavlovsky, CEO and Product Manager, to learn how the company started and what fuels the team's creativity. Atlassian:...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events