locked
is there any reasonable way to chain workflows? RRS feed

  • Question

  • After having worked with OCS for several months, one thing is especially frustrating.  How are we supposed to build factored, meaningful, maintainable workflows without the ability to chain them together?

    Here's a simple scenario:

    Outside callers are routed to the MainOffice workflow - based on the "2 Level Interactive Template"

    There are 3 options on the phone menu, allowing the caller to contact the right department:

    1. Sales
    2. Helpdesk
    3. Customer Service

    On the back end, these 3 caller options are handled by 3 different agent groups/queues, which the agents would sign in to/out of using Communicator.

    I'm assuming that since this top level MainOffice workflow requires caller input, the Basic and Enhanced Hunt Group workflows cannot be used at the top level.

    Since the main (business hours) flow of an interactive workflow only gives us one chaining option - to call a queue - we're forced to send the caller directly into the agent group/queue.

    But from the top level MainOffice workflow we'd prefer to call three individual hunt group workflows, one for each department, rather than direct to a queue.  There are two (seemingly legitimate) reasons to do it this way:

    1. The department hunt group workgroups - Sales, Helpdesk, or CustomerService - will show up in Communicator as a Contact Card.  This enables internal users to easily transfer calls between queues by name.

    2. When a call arrives at an agent's desk, the "toast" (notification window) will show the agent from which queue the call arrived.  This is important for several reasons, for example if I'm logged into multiple queues, I'd like to know who's calling, through which path (including direct to me) before I pick up the call.

    Maybe I'm missing something blindingly obvious here, but OCS does not seem to support any simple way to accomplish this scenario and gain these benefits.

    Gurus, can you help?
    • Edited by Jon Lawrence Tuesday, August 4, 2009 1:42 AM misspelling
    Tuesday, August 4, 2009 1:40 AM

Answers

  • Hi Jon,

    What your wanting is not in the design but I think I may have a work around for you using the timeout function of a Queue.This would probably require the either the one or two tier group to begin with depending on who many departments you want to send stuff to. First create your three contact objects eg sales, helpdesk and customer service. Then create how ever many queues and set the time out for those three queues really low like 1 second and send them to the SIP uri contact objects you created in the first step. With those three contact objects create three new work flows.

    Does that make sense? I havent tested it my self but I sure with a little messing around it should work. You may need to create some service accounts in AD to put in the fake queues if it is required they need a agent in there.

    Cheers
    Chris


    http://voipnorm.blogspot.com/
    • Marked as answer by Jon Lawrence Tuesday, August 4, 2009 5:33 PM
    Tuesday, August 4, 2009 2:10 AM

All replies

  • Hi Jon,

    What your wanting is not in the design but I think I may have a work around for you using the timeout function of a Queue.This would probably require the either the one or two tier group to begin with depending on who many departments you want to send stuff to. First create your three contact objects eg sales, helpdesk and customer service. Then create how ever many queues and set the time out for those three queues really low like 1 second and send them to the SIP uri contact objects you created in the first step. With those three contact objects create three new work flows.

    Does that make sense? I havent tested it my self but I sure with a little messing around it should work. You may need to create some service accounts in AD to put in the fake queues if it is required they need a agent in there.

    Cheers
    Chris


    http://voipnorm.blogspot.com/
    • Marked as answer by Jon Lawrence Tuesday, August 4, 2009 5:33 PM
    Tuesday, August 4, 2009 2:10 AM
  • Hi Chris,

    Thanks for your quick reply.  Here's what I understand is your proposed workaround:

    MainOffice (one or two level interactive workflow)
          |
          +---- Sales(Q1) ----> SalesContact ----> Sales(Q2)
          |
          +---- HelpD(Q1) ---> HelpDContact ----> HelpD(Q2)
          |
          +---- CustS(Q1) ---> CustSContact ----> CustS(Q2)

    As far as I know, when using OcsUMUtil to create URI Contact Object I can only configure the contact to transfer to an "Auto Attendant," which is part of Exchange/UM.

    If correct, this means the above workaround would not be possible.

    Otherwise, do you know of a way to configure a Contact Object to transfer to a queue?
    Tuesday, August 4, 2009 2:34 AM
  • Maybe I answered my own stupid question, specifically:

    1. in the above diagram, the Q2 objects (Sales(Q2), etc) should actually be workflows as you stated, but I misinterpreted as queues.

    2. since we're transferring from a Contact Object to a Workflow, simply associate the Contact Object with the Workflow object and OCS does the rest.

    So to correct above:

    MainOffice (one or two level interactive workflow)
          |
          +---- Sales(Q1) ----> SalesContact ----> Sales(W) ----> Sales(Q2)
          |
          +---- HelpD(Q1) ---> HelpDContact ----> HelpD(W) ---> HelpD(Q2)
          |
          +---- CustS(Q1) ---> CustSContact ----> CustS(W) ---> CustS(Q2)

    Where:

       (Q1) = a queue with 1 second timeout;
       (W)  = a hunt group workflow, one for each department - visible in Communicator and Toast
       (Q2) = the queues we associate with the agents and groups, with actual timeouts and overflows

    Is this on the right track?

    If it works then this seems like a reasonable workaround.  Too bad OCS makes us jump through so many hoops to accomplish this seemingly simple result, but I guess we take the bad with the good.
    Tuesday, August 4, 2009 3:12 AM
  • I think you have it down Jon. This is what I believe should work. You create the extra contacts using the RGSCOT.exe utility. Here is the link

    http://technet.microsoft.com/en-us/library/dd425139%28office.13%29.aspx


    OcsUMUtil is used for exchange OCS integration and should not be used to create contact objects to be used for Response groups. RGSCOT can be used to create, edit and delete contact objects in AD specifically for the use in OCS. You should really give these other contacts their own DID's as well. This will enable them to be able to stand on their own as a stand alone ACD application giving them more potential use.

    Hope this helps. Let me know if this works out for you.

    Cheers
    Chris

    http://voipnorm.blogspot.com/
    • Edited by VoIPnorm Tuesday, August 4, 2009 2:24 PM Added comment
    Tuesday, August 4, 2009 2:16 PM
  • Chris, I've tested and this does in fact work.  Thank you again for your help.
    Tuesday, August 4, 2009 5:33 PM
  • No problem Jon, glad I could help. Give me a good idea for a blog entry.
    http://voipnorm.blogspot.com/
    Tuesday, August 4, 2009 11:02 PM
  • One caveat to consider: when queues and workflows are chained in this manner, the caller hears ringing instead of music on hold while waiting in the final queue.  This may or may not be desirable.

    Note that you can eliminate the Q1 piece above, which is the forwarding link from the top-level auto-attendant, and still get benefit #1, which is a "Contact Card" in Communicator for transferring calls into queues.

    If you connect the top-level auto-attendant directly to the final queue, music-on-hold works but the toast at the Communicator endpoint does not show that the call came through the queue until the call is answered.

    This is all very confusing, but it does work.  If anyone would like a Visio of this setup, contact me by email: jlawrence (at) databalance.com.
    Tuesday, August 4, 2009 11:54 PM