Hi Stéphane
It's my understanding we can implement some behavior so it will suite your use-case.
For example a radiobutton that the end-users need to press if the ticket does not exist on the destination side,
and a customfield to enter the Jira ticket for when the ticket does exist.
If you want to see a demonstration of this; please book a demo here:
Thank you.
Kind regards,
Mathieu Lepoutre
Hi Mathieu,
Following your suggestion, a Salesforce user would provide the Jira Key and a flag to make it clear he wants a Connect (instead of creating a new Jira ticket based on the Case).
So, we have a Case where it is written a Jira Key and the desire (aka the checkbox) to connect to said ticket on Jira.
How Exalate would process that information? I assume it will need a trigger to start the synchronisation (we do it when the Case is used to generate a new Jira Ticket).
What should be the script syntax? The SF outgoing should set the key & flag in the replica (nothing else, compared to the Exalate action). On Jira side, what will differ in the incoming script to connect instead of create (while keeping the create feature) ?
Currently, there is the "if (firstSync)" condition that contains all the fields' mapping. It also includes "syncHelper.syncBackAfterProcessing()" that ensures the Case get details of the newly created Ticket.
I guess we should have something similar, but for the "connect".
Any tips?
Regards,
Stéphane
Hi Mathieu,
On Salesforce side, on Case, I have a JiraKey__c and a JiraConnect__c fields. On a test record, JiraKey__c contains the remote URN (ex: 'PROJ-1234'), JiraConnect__c is set to true (it is a checkbox).
The outgoing script populate a replica field "connect" with this Salesforce field's value, and the replica.key field
I set an Exalate trigger that detect when the flag is set:
| Case | Events: create/update | JiraConnect__c = true |
On Jira side, I set a minimal script in an attempt to only start a feedback action from Jira to Salesforce.
if (replica.connect) {
syncHelper.syncBackAfterProcessing()
return
}If the flag set on Salesforce is true, just do a feedback (aka: do not attempt to create a new Jira Ticket).
That produces nothing. No new record on Jira (that's expected), and no connection.
If I use the "Connect" button from the Exalate component on Salesforce, the link is set between Case and existing Ticket. But no data is exchange. So the Case (and the support agent reading it) has no clue on the Ticket status (we have Case fields dedicated for that, that work for an "Exalte").
As the relation seems to be only known by Exalate, neither Salesforce of Jira can reports on the Case/tickets that are connected.
My takeaway is that the incoming scripts are useless for a "Connect".
My initial question remains: how could we distinguish (and take actions) an "Exalate" from a "Connect"?
Regards,
Stéphane
Current workflow is:
When needed, a SF Case gets some dedicated fields populated, that triggers Exalate's trigger that get Case's data and create a new Jira Ticket. From there, the Jira Ticket is processed and the SF Case shows key information coming from Jira (in a dedicated set of fields, eg: no overwrite of case's fields like Status, Priority, Subject, ...). When Jira Status' change (and few other fields), thank to synchronisation, the info is updated on Salesforce and a SF trigger set a notification to the SF Agent who is kept up-to-date with Jira progress.
It is a 1-1 relation, one Case creates one Ticket and Ticket's updates are reflected on the Case.
The future we're aiming to:
We want to use the "Connect" ability, so a Case (or more) can be connected to an existing Ticket.
We rely on the Exalate component in SF to achieve that. We include it in the main page of a Case, with filter so only few selected users can see it.
When Agent sees a Case that match a Ticket he already knows about, he "Connect" the Case to the Ticket.
How can we distinguish an escalation (Case to new Ticket) from a connection (Case to existing Ticket)? Any special property in Groovy script?
We still want the SF Case to show some information coming from Jira through synchronisation, but we don't want the SF notification (mainly the one that says "You created a ticket PRJ-123 based on Case XYZ"). Those notifications are managed within Salesforce via Case Triggers. What would be the condition that helps knowing the context of the relation.
Regards,
Stéphane