Is it possible to configure an Inbound Field Rule to change the Assignment Group and also clear the value in the Assigned To field?




In the PagerDuty App for ServiceNow, is it possible to configure an Inbound Field Rule to change the Assignment Group on an Incident and also clear the value in the Assigned To field upon page Acklowledgement? I have a rule configured that will change the Assignment Group no problem. However, I created another rule to blank out the Assigned To field but the Default Value field is mandatory and requires that text be entered.



(Demitri Morgan) #2

Hi @bostonsnow,

While it is possible to set the assignment group in an inbound field rule, I wouldn’t recommend it unless you want the incident getting automatically resolved or sent to a different escalation policy in PagerDuty. That’s because there are business rules that perform such operations automatically when there is a change in the assignment group.

To elaborate: if the other assignment group is provisioned to PagerDuty (meaning, it has an escalation policy associated with it), then the integration will delegate the incident to the other escalation policy, returning it to the triggered state and paging the people in that escalation policy. Otherwise (if the group is not provisioned), the it will resolve the PagerDuty incident and mark it as “unlinked” in ServiceNow, as it is at that point considered to be handed off to group that is working outside of PagerDuty.

If this is the intended effect, then (and correct me my assumptions are incorrect) there is less need to blank out the assignment field, because when the next person in PagerDuty acknowledges the incident (assuming that you have designed the lookup script in the inbound field rule to exclude certain cases in acknowledgment), then the incident will get automatically assigned to them in ServiceNow.


Hello Demitri,

Thanks for the quick response! Our Tier 1 group, which does not exist in PagerDuty, always maintains ownership of the Incident. We escalate via Incident TASK. When we configured PagerDuty in our Dev instance, we were really surprised to discover that the application did not allow paging from TASK. So, we are trying to come up with a workaround. Since we can only page from INC we are forced to reassign the INC away from Tier 1. Once the page is acknowledge, it needs to go back into the Tier 1 queue (reassign INC to Tier assignment group). I was able to have the Assignment Group field changed upon page acknowledgement, I just can’t figure out how to clear the Assigned To field. We are only using the PD Incident until the page is acknowledged. Once the page is acknowledged our teams work the escalation from SNOW. Any ideas?



(Demitri Morgan) #4

Hi @bostonsnow,

Thank you for sharing with us about your use case. This helps us prioritize and gauge demand (among other things) for future enhancements.

I would also like to add that (as has been pointed out to me) if one wants to set assignment group when handling a webhook from PagerDuty, a better way than in an inbound field rule would be to add arbitrary code to the PagerDutyInboundCustomScript script include. This would grant a lot more flexibility.


@demitri Thanks for the additional information. We did consider this, my understanding is that going that route might make us unsupported based on the PagerDutyInboundCustomScript Description…

“/*** Changes made to this script are not supported by PagerDuty ***/”

Or do we remain in supported status but only the script customizations are unsupported?

(Charlotte Sarfati) #6

Hi @bostonsnow,

Yes, your account will remain in supported status but the script customizations themselves are unsupported. As with any other component, customizations are owned by the party who performs the modifications, and so that party would also need to handle debugging and testing of the customized product. However, it’s safer to make the modifications in the custom script include than anywhere else because we do not anticipate updating anything in that file (which means that customizing it won’t necessarily break the app during upgrades the way that customizing other components can).

(system) #7