Answer by Ariel Aguilar on 18 May 2022
Hi there!
This can be achieved with the following scripts:
Sync Requester(reporter) from Zendesk to Caller ID in ServiceNow:
Outgoing Sync Zendesk:
replica.reporter = issue.reporter
Incoming Sync ServiceNow:
entity.caller_id = nodeHelper.getUserByEmail(replica.reporter?.email)?.key
Sync Caller ID from ServiceNow to Requester (reporter) on Zendesk:
Outgoing Sync ServiceNow:
replica.callerMail = nodeHelper.getTableByLink(entity.caller_id?.link)?.email
Incoming Sync Zendesk:
issue.reporter = nodeHelper.getUserByEmail(replica.callerMail)
Keep in mind that this will only work if the reporters have the same e-mail on both sides.
If the reporters have different e-mails on each side, you can use a mapping to map between users like so:
Incoming Sync:
def userMapping = ["snowuser@example.com":"zendeskuser@example.com"]
issue.reporter = nodeHelper.getUserByEmail(userMapping[replica.callerMail])
Another option if you don’t want to map users would be to try to find a user with the same e-mail as the source side in the destination, and if it’s not found, then set a default user:
Incoming Sync:
def defaultUser = nodeHelper.getUserByEmail("defaultuser@example.com")
issue.reporter = nodeHelper.getUserByEmail(replica.callerMail) ?: defaultUser
Kind regards,
Ariel
Comments:
Corey Nunn commented on 18 May 2022
Thank you, this worked for the Zendesk → ServiceNow direction, but not the other way. When receiving connected tickets in Zendesk, the reporter field is filled in with my own user account, Corey Nunn. Do you have any ideas as to why?
Ariel Aguilar commented on 19 May 2022
Hi Corey,
I suspect you are missing something, can you share the lines used?
Kind regards,
Ariel
Corey Nunn commented on 19 May 2022
We used the first incoming/outgoing lines you provided, with the expectation that emails match across systems. We tested using email addresses of users we knew existed in both systems.
Ariel Aguilar commented on 19 May 2022
Can you share the Outgoing script from SNOW and Incoming script from Zendesk?
Corey Nunn commented on 20 May 2022
Incoming script:
if(firstSync){
//Decide on the first sync, which entity you want to create based on the remote issue type
issue.setStatus(“open”)
issue.reporter = nodeHelper.getUserByEmail(replica.callerMail)
//issue.customFields.“5355989906452”.value = “exalate_realogy_escalate”
}
issue.summary = replica.short_description
issue.description = replica.description ?: “No description”
issue.attachments = attachmentHelper.mergeAttachments(issue, replica)
issue.comments += replica.addedComments
issue.label = “escalation_from_realogy”
//if(replica.state == “In Progress”)
//issue.customFields.“Waiting On”?.value?.value = “Customer”
if(replica.state ==“Resolved”){
issue.setStatus(“solved”)}
def priorityMapping = [
“1 - Critical”:“urgent”,
“2 - High”:“high”,
“3 - Medium”:“normal”,
“5 - Enh/Def”:“low”]
def priorityName = priorityMapping[replica.priority?.name] ?: “low”
issue.priority = nodeHelper.getPriority(priorityName)
Corey Nunn commented on 20 May 2022
outgoing from SNOW:
if(entity.tableName == “incident”) {
// replica.key = entity.key
replica.short_description = entity.summary
replica.description = entity.description
replica.attachments = entity.attachments
replica.comments = entity.comments
replica.state = entity.state
replica.priority = entity.priority
/// replica.u_escalated_to_moxi = entity.u_escalated_to_moxi
/*
Use a field"s internal name to send its value
Example: Resolution Notes -> resolution_notes
This works for all other entity types as well
replica.resolution_notes = entity.resolution_notes
*/
}
replica.callerMail = nodeHelper.getTableByLink(entity.caller_id?.link)?.email
//any other entity can be synced using the table name and the entity variable
if(entity.tableName == “cmdb_ci_business_app”) {
replica.key = entity.key
replica.summary = entity.short_description
replica.description = entity.description
replica.name = entity.name
}
Ariel Aguilar commented on 24 May 2022
Hi Corey,
I found what the problem is, it is found on your Outgoing sync rules:
You may add the rule for caller inside the Entity incident:
if(entity.tableName == "incident") {
// replica.key = entity.key
replica.short_description = entity.summary
replica.description = entity.description
replica.attachments = entity.attachments
replica.comments = entity.comments
replica.state = entity.state
replica.priority = entity.priority
replica.callerMail = nodeHelper.getTableByLink(entity.caller_id?.link)?.email
Corey Nunn commented on 24 May 2022
we tried that originally, but it didn’t work. Which was why we had it outside in a different section. It still does not operate as expected in the way you have posted above.
Ariel Aguilar commented on 26 May 2022
Sync ServiceNow Caller to Zendesk Requester
Whenever setting up a sync, and something doesn’t work, it is always good to check step by step and find the reason why it fails. The sync flow is always the same:
(ExSN - Exalate for ServiceNow, ExZD - Exalate for Zendesk)
- ExSN picks up a change from ServiceNow
- ExSN forms the message which will be sent to the other side
- ExZD Receives the message and processes in the incoming sync processor
- ExZD applies the result of the processing onto the issue object.
Ways to troubleshoot are documented, but it boils down to check if Exalate is behaving correctly. For instance, it is always good to check if the replica (the message) contains the information you expect. This can be done by interrupting the flow (add a debug.error(“Hello world”)) to the incoming sync and check the remote replica in the resulting error. If the replica contains the information you expect - move on, if not find out why it isn’t by inspecting the outgoing sync. Then, check what is being applied onto the ticket.
Thanks,
Ariel
Corey Nunn commented on 26 May 2022
We tested this over and over and the requester is still being set as myself instead of the test contact (which does exist in both systems). I wonder if there’s some other setting or feature that is overriding our incoming and outgoing script. Do you have any ideas?
Ariel Aguilar commented on 27 May 2022
You need to determine where the problem is generated. Is it when sending from Snow or when receiving on Zendesk? Did you check the replicas? You sure you tried to sync an Incident and the rule is set for incidents or is it a Request Item for example? You can use the Entity sync status or debug.error on ServiceNow to see if the email value is added. Then, check where is the actual problem.
Kind regards,
Ariel
Corey Nunn commented on 27 May 2022
Ariel we got it working! Thank you so much for your help