How far to take Response Groups

I’m half way through a 3 phase project that started with a Lync Server 2010 to 2013 migration, currently deploying Enterprise Voice, and the final phase will be to deploy a contact centre with PCI compliant call recording.

My client is understandably excited about ditching their Avaya IP Office PBX, but before we start the ACD phase they were very keen to see how they could migrate some of their old hunt groups and call flows to native Response Groups. One in particular, ended up needing 3 Workflows, 6 Queues, 2 Groups, and a new Lync user to act as a ‘place-holder’. I thought it was interesting enough to write about. I’ll do my best to explain it in words first, but will probably end up drawing a Visio diagram at the end anyway, so here we go.

“A caller dials up, if it’s in-hours, to play a welcome message asking the caller to wait, then pass the call to a group of 6 agents in a pre-defined order, for 10 seconds each. If it’s out-of-hours, to play a message to ask the caller to choose an ‘on-call’ agent (by pressing 1,2,3 or 4), each to call that specific person’s mobile phone number.”

On the face of it, it sounds fairly straight forward, right? Lets start from the top and see what we can actually do to achieve this.

Before we go on any further, I would like to point out that I’m certainly NOT recommending the following to my client, and at no point suggested actually using the resulting ‘plate of spaghetti’ in production. Perhaps I should have just said “No, wait for your ACD”, but, working on the clear understanding that this is purely to feed my clients curiosity (and my own), where’s the harm?

Firstly, “Can a Response Group Workflow play a different message in-hours vs out-of-hours?”. Simply put, No. The options available to us are a ‘Welcome Message’ which gets played as soon as the call is picked up, no matter what, and an “Out-of-Hours Message”. Hmm, that doesn’t quite work for us. Here comes the first workaround… A “Hunt Group” Workflow which evaluates the business hours without any announcements, then elects to forward the call out-of-hours to a SIP Address of another Workflow (which will play a “please select from the following agents” message and do the IVR part – I’ll come back to this later) so that’s that bit sorted for now.

Before we get ahead of ourselves, for our In-Hours requirement on this first Workflow, we would need to play a message after we’ve established it’s In-Hours, and then forward to a queue, so lets ask “Can a Response Group Workflow forward to another Workflow if ‘successful’?”. The answer again, is no. The only outcome of a ‘successful’ Workflow is to select a Queue, but this does gives us the option to use (and abuse) the ‘overflow’ feature, and specify a SIP Address of yet another Workflow.

The Overflow feature of a Queue is designed to take the load off your agents, if there are 5 agents, and 50 people waiting in the queue, you may decide that enough is enough and all new callers are told to hang up and try again later, or given the option to leave a message. We can use this to our advantage and basically tell the Queue that the maximum number of calls in the queue is zero, so it will always overflow. For this to actually work the Queue needs a Group associated with it, and an agent in the group, otherwise the call with simply end, and you’ll receive the following error in the Event Log of the server.


Once in a while Microsoft get it right, and you get an error message you can understand, and is exactly spot on. But I don’t want a specify a Group, nor a User, as this should overflow instantly to the specified SIP Address. This is where the ‘NullGroup’ and ‘NullUser’ come in. After creating a Lync-Enabled User (that will never receive a call) in a new Group, and associating that with the Queue, it works.

This next bit is simple, create a Workflow with a Welcome Message and specify a Queue with an Agent Group associated, configured with Participant Policy set to Informal, Alert Time set to 10 seconds, and Routing Method set to Serial.

Lets put together what we have so far in-front of, and behind the scenes…

  • Caller’s View “In-Hours” – A caller dials a number, they hear a message asking them to wait, then a ringing tone, and an agent answers the phone.
  • Lync’s View “In-Hours” – A caller dials a number and gets a Workflow that checks if the call is in-hours, then calls a queue, overflows, and forwards to SIP Address of another Workflow which plays a message, calls a queue, and the agents phones will ring, and an agent picks up the phone.

Coming back to the IVR for Out-Of-Hours, the next question is “Can a Response Group forward to a telephone number”. Yes, if a result of being outside business hours, or a holiday, but not as a result of an IVR option. So, unfortunately, the answer is once again, no. But we can use the Overflow feature of another Queue to forward to a Telephone Number. With a few more bits of Lego, and sticky tape we have our finished call flow.

  • Caller’s View “Out-Of-Hours” – A caller dials a number, they hear a message asking them to select an ‘on-call’ agent by pressing 1,2,3, or 4, then a ringing tone, and an agent answers the phone.
  • Lync’s View “Out-Of-Hours” – A caller dials a number and gets a Workflow that checks if the call is out-of-hours, forwards the call to a SIP Address of another Workflow, which plays a message asking them to select an ‘on-call’ agent, and calls a Queue, which overflows, and forwards the call to a telephone number, it rings, and an agent answers the phone.

I told you it was difficult to explain, so here’s the Visio I threatened you with. (Blue = Workflow, Green = Queue, White = Group). Click to enlarge.


The only major drawback is when calling this from a Lync Client, it pops up a new call window each time it forwards through each Workflow, so it looks a bit like the end of the Solitaire card game, which also introduces a small but unwanted delay and confusion as the call initiates.


For all you PowerShell fans out there, life doesn’t get any easier. The following code is not complete, but you should get the idea of what’s going on, and what it takes to rustle up something a bit more than a standard response group.

Don’t forget to apply a voice policy to the Workflows as they’ll need to be able to dial out. (And a Dial Plan if there are no rules in your Global).

Conclusion – How far should you bend and twist Lync Response Groups

Although when calling from PSTN, the experience is smooth and quick, unlike the Lync Client, that doesn’t mean you should entertain taking it this far with the built-in Response Group functionality. It’s difficult for any Helpdesk, or Lync User Admin to understand, as this leaves behind a messy and confusing bunch of strange Workflows, Queues, and Groups, and not to mention a funny taste in the mouth.

Microsoft has done a great job of providing ‘some’ functionality that covers most simple cases (Hunt Group Workflow) and even gone as far as to allow a 2-Level, 4-Option IVR with text-to-speech, and speech recognition (Interactive Workflow), that’s not too shabby at all!

But all is not lost, in the guise of UCMA, Lync has embraced 3rd party extensibility, and figuratively thrown the doors wide open to developers, enabling them to create advanced call handling software with very flexible rules, allowing you to create complex call flows for a wide variety of business needs.

If this particular call flow remains a requirement for my client, I will post a follow-up article explaining how it was achieved using their selected ACD software.

Don’t have nightmares…

Tweet about this on TwitterShare on LinkedInShare on Facebook
Pin on PinterestShare on Google+Digg thisShare on RedditShare on StumbleUponEmail this to someone

About Graham Cropley

Working as a Senior Consultant for Skype for Business, Exchange, and Office 365.


  1. Your (excellent) note is entitled “How far to take response Groups”? I’d like to take it as far away as possible and then drop it off the highest cliff I can find! I recently “migrated” an installation in Switzerland from the original predecessor of Lync – a product named ePhone developed in Switzerland that MS bought and absorbed into what became Lync. ePhone had a very powerful ACD, however the gateway hardware was no longer available so to remove that risk the customer decided to migrate to Lync. It proved very hard to even approach the same functionality with native Response Groups for all the reasons that the author mentions and more.

    Response groups in 2013 are unchanged from Lync 2010. The impression I have is that MS are abandoning it and want to leave it to third parties, but those solutions have not yet fully emerged.

    Our resulting installation was truly “Spaghetti”, did not have the functionality of the old solution and was not something I am proud of.

    I hope something better emerges!


  2. Richard, I recommend you look at MaxACD, it is an easy to use, full featured Lync certified call center:
    1. IVR
    2. Agent client
    3. Supervisor client (listen, barge, whisper)
    4. WG Call Recording
    5. Reporting

  3. Nice readable article, love the reference to a bowl of spaghetti and useful information. Thanks

  4. Well written blog, I share your pain! Which ACD solution was implemented in the end?

  5. Wow.
    I was just designing a similar scenario for a client that wanted a “basic” IVR..
    Something I could build in Switchvox in minutes turned into a massive planning and design session very similar to yours in the fact that I needed dummy queues and work flows.

    I wasn’t, however aware of the Holiday message AFTER the greeting message… Seems a bit silly when you have told the user to Press X already..

    Now I just wish that RGS had some logic for when no agents are logged in…

  6. I should also point out that using a workflow that is “always” out of hours is a nice way to play a message and then forward a call without having to dump it to a null queue first

    • Jean-Edouard Plessix

      I did that and I resolved many issues in my Lync scenario.
      This is the easiest way to forward to SIP URI or Telephone number.

  7. When I run a script to work with Sky4B, everything completes but performing a new or set csRGSWorkFlow fails with tech following cryptic message, New-CsRgsWorkflow : Value cannot be null.
    Parameter name: Question
    Have you experienced this error?
    I tired whittling down some tress, but still experience the same error? Also tried to recreate the Workflow with no actions, and received the same error when I went to activate the WorkFlow.


    • It sounds like you’ve not specified a Question object to the New-CsRgsCallAction that’s used when creating or setting the workflow? Basically meaning the workflow object you’ve built is not complete or something is missing?

Leave a Reply

Your email address will not be published. Required fields are marked *