Answer by Jack Handy on 07 October 2021
I just worked this out myself a few days ago. Hereās what I did.
On the ServiceNow side:
// Outgoing
replica.priority = entity.priority
// Incoming:
//first set up a map between the two to translate the input from ADO into something SNOW could use:
def PriorityMap = [
"1" : "1 - Critical",
"2" : "2 - High",
"3" : "3 - Moderate",
"4" : "4 - Low"
]
// next get the input from ADO and map it to the appropriate priority type for SNOW. // If you get something you don't expect then just call it "4 - Low"
def targetPriority = PriorityMap[replica.priority.name] ?: "4 - Low"
entity.priority = nodeHelper.getPriority(targetPriority)
ADO side:
// Outgoing
replica.priority = workItem.priority
// Incoming
// same process in reverse, create a mapping for disparate data types:
def PriorityMap = [
"1 - Critical" : "1",
"2 - High" : "2",
"3 - Moderate" : "3",
"4 - Low" : "4",
]
// Use the PriorityMap to translate SNOW into ADO and then the helper to put it in the correct data type format
def targetPriority = PriorityMap[replica.priority.name] ?: "4"
workItem.priority = nodeHelper.getPriority(targetPriority)
Thatās what worked for me. Hope that helps!
Comments:
Chris Lund commented on 08 October 2021
Jack Handy Thank you for that piece of code, but we are still having issues in syncing the priorities. On the outgoing from SNow to ADO, the priority field is updating but only to P4, in the payload the priority value is still being sent as the urgency value. We have different values for urgency and priority, example urgency = ā1 - Highā and priority = ā1 - Criticalā, so mapping these values isnāt working because it is sending a value we arenāt expecting so it always get set as 4.
Conversely on the incoming to SNow only the urgency is getting set, it will update the priority field if the urgency/impact matrix determines a new priority. I realize that we could and probably will just copy that matrix over to ADO and determine priority the same way, but now Iām just curious if itās even possible to send the actual priority value in the payload
Jack Handy commented on 08 October 2021
I was going at this the wrong way. I was able to reproduce this. I thnk itās a bug.
On the second part:
You can send priority but I donāt think SNow will accept the input to that field as itās ācalculatedā from the other values.
Jack Handy commented on 08 October 2021
I reported this to them as a bug. In the meantime if you wanted to have some fun you could put together a matrix of possible values:
impact & urgency = priority
1 & 1 = 1 Critical
1 & 2 = 2 High
1 & 3 = 3 Moderate
2 & 1 = 2 High
2 & 2 = 3 Moderate
2 & 3 = 4 Low
3 & 1 = 3 Moderate
3 & 2 = 4 Low
3 & 3 = 4 Low
Then use a switch or if statement to build the correct value to send and use something like
if(entity.impact.contains(āLowā) && entity.urgency.contains(āHighā){
replica.priorityVal = ā3 - Moderateā
}
I havenāt tested this but I think it should work until this gets explained/fixed.
Francis Martens (Exalate) commented on 09 October 2021
I can confirm this was a bug.
We mixed up urgency and priority.
To keep backward compatibility we had to introduce
- priorityValue (to reflect the priority field)
- urgencyValue (to reflect the urgency field)
Check for this How to sync urgency and priority between ServiceNow and Jira
Which is pretty similar to the way it can be done between ServiceNow and Azure DevOps
Chris Lund commented on 12 October 2021
Francis Martens (Exalate) Thanks for that link, I was able to fix the priority issue and now it is syncing between the 2 systems using priorityValue. If you had not provided that I was planning on implementing something along the lines of what Jack Handy commented below. Thanks again for all your help!