The Problem

Users calling in to a existing Response Group Service are getting calls dropped when the call steps through the workflow and is directed to the RGS Queue. All other Workflows are working fine.

History

This started after an admin was tasked with re-directing calls to the workflow DDI\DID in question to another workflow temporarily. It was when they switched the calls back that the issue revealed itself.

The Evidence

Checking the Event Log on one of the Front Ends I find an error alluding to a workflow issue. Event ID 31117 states that “the workflow encountered a critical error”.

Monitoring Database shows a Diagnostic ID 26029 with a description “Call is disconnected because of invalid configuration”

So by now I was thinking that there is some sort of configuration issue with the workflow or inherently the queue, or group. I checked and double check, everything looks fine on the surface.

Finding the culprit

With no further information to go by I took a stab at the possibility that an invalid agent SIP address was added to the group (seen a similar issue where that was the cause, see here). Nope, all good.

With only three variables, the Workflow, the Queue and the Group, I decided a quick process of elimination should flush out the hog.

Turning to the Workflow, I changed the destination Queue to one that I knew was working. Tested it and, well that worked. So the Workflow is fine.

Next up the Queue, I removed the associated Groups from the queue and added groups I knew were working. OK so that worked, calls went to the test group members. So now I knew it was the Queue that was causing the pain.

Keeping it simple, I just deleted the Queue, invoked replication and re-added it. A quick test call and voila..Sorted!

Response Groups can be really powerful, they can also be a royal pain in the behind when something goes wrong.

TIP

Making changes to RGS takes a few minutes to set, I usually invoke replication before testing any changes.