Sync Multiple Related Salesforce Objects (Contact & Account Linked to a Case) to Jira
Salesforce often involves multiple objects that have an association between them. For instance, an Opportunity can have an Account or Product association.
And then, these related objects in Salesforce need to be synced over to Jira for better visibility to different teams.
This article is to help you understand how this can be achieved using a 3rd-party integration solution like Exalate.
Note: You can also refer to the detailed blog here.
The use case
We have a Case object that has a Contact and Account linked to it and that needs to be presented on the Jira side.
The specifics:
- Case information like subject, description, comments, status, and attachments needs to be synced bi-directionally between Jira and Salesforce.
- On the Jira side, there are 2 custom fields: ‘SF Contact’ and ‘SF Account’ to display the Account and Contact information related to the above Case.
- Any changes or updates in the Account or Contact need to be reflected on the Jira side.
The Challenges:
- Fetching information related to Case, Account, and Contact individually from Salesforce to Jira can be simple. The real challenge lies in connecting the Account and Contact to the correct Jira issue that has been created while syncing the Case.
- Changes in the Account or Contact should pass over correct updates to the synced Jira issue.
Using a 3rd-party Integration Solution: Exalate
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.
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.
Implementation with Exalate
Before starting the implementation we need to install Exalate on both Jira and Salesforce.
Note: You can also watch the Exalate installation videos of Jira and Salesforce if you prefer so.
Then a connection must be established between them. There are 2 types of connections that are supported: Basic mode and Script mode.
Keeping in mind the advanced configuration of this use case, it is recommended we use the Script mode connection.
Configuring the Connection
Once the connection has been set up, we start configuring it. ‘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 are present at the Salesforce end too.
As seen in the script below, all the information (sent or received) is through something called ‘replica’.
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.
Outgoing Sync: Jira
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.
Step 1: Outgoing Sync, Salesforce
- Line 4: Here, the first ‘If’ condition checks whether the entityType is ‘Case’.
- If yes, then Subject, Description etc for the Case is copied into a replica to be sent over to Jira.
- Line 13: replica.“Type” carries the type of the Salesforce record, for instance, Case, Account or Contact. This is used at the Jira end to recognize what type of entity is coming over.
- Line 15 and Line 21: The next 2 if conditions are to send specific Account and Contact related information.
You can find the entire snippet here.
Step 2: Incoming Sync, Jira
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 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.
Right now let’s go to the other end (Salesforce incoming). We will have a look at the remaining code in the ‘Incoming sync’ of Jira in step 4 again.
Step 3: Incoming Sync, Salesforce
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.
Step 4: Incoming Sync, Jira Now coming back to the incoming sync on Jira, it’s time we display the fetched Account and Contact details.
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.
Wrap it up
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 which uses Groovy-based scripts to implement even the most advanced or complex use cases.
