Results 1 to 6 of 6

Thread: Toolstep to query active workgroups

  1. #1
    Join Date
    Aug 2016
    Posts
    8

    Toolstep to query active workgroups

    We have a ongoing issue with agents who change their status in order to take calls in different work groups.
    Generic example:
    When an agent goes to custom status A to take calls from work-groups 1, 2 and 3, and then the agent changes to status B to take calls in workgroups 4, 5, and 6; the agent will remain assigned to 1, 2, and 3 even though the agent has left status A.
    The problem is that when an agent leaves status A, they are still connected to work groups 1,2, and 3 when they go to another "Available Group". I am trying to find a tool step that would query the assigned work groups and un-assign the work groups from the agent when they change status's.

    Is there a tools step that will query the agents assigned work groups so that we can unassign the agent from the queues with the work group deactivate tool step or something else?

  2. #2
    Join Date
    Oct 2010
    Posts
    94
    Hi Vincent!

    I'm a little unsure of what you are trying to achieve here. Statuses aren't designed to be used for Workgroup Activations. Can you provide some more background?
    Paul Simpson
    Technical Sales Systems Engineer

  3. #3
    Join Date
    Nov 2006
    Location
    Anderson, IN
    Posts
    901

    queue activation

    This sounds terribly complicated... and I'm not certain whether this will work with status messages quite like you are envisioning. Why not just use queue activation and grant the agents permission to manage their own activation in the different workgroup queues?

  4. #4
    Join Date
    Aug 2007
    Posts
    157
    I am assuming you already have a handler firing at the changing of the status here, but you can get the workgroup memberships of a specific user by using the "Lookup" tool. For the parameters use Key Type : "User", Search Attribute Type : "Queue Identifier", Value to Use in Search : "User Queue:" & {{userid}}, Attribute Type: "Workgroups". Assign the Attribute Value to a new variable of string type. This will contain a "pipe" ( | ) separated list of workgroups if the step is successful which you can then pass to the Parse String step to produce a list of string object. Loop through the list of string, and activate/deactivate based on your requirements using the ACD tools.

    I can sort of understand the use of a controlled change at the agent level to manage the memberships. There may be a better way to manage this, but I could see a use. In the scenario explained above there appears to be a group of related workgroups that agents must be activated in at the same time all of the time e.g. if they are active in workgroup 1, the must also be active in workgroup 2, and 3, but not active in workgroups 4, 5, or 6. Placing this activation on the status allows the system to control the activation, and removes the chance that an agent may activate themselves in workgroup 1, only for them to forget to deactivate from the other workgroups, or forget to activate themselves in workgroups 2 and 3.

  5. #5
    Join Date
    Oct 2010
    Posts
    94
    The issue I see with all of this is that you may end up having to have dozens of statuses duplicated to allow for varying system and user-selectable statuses in each situation.

    A cleaner approach may be to have two custom buttons, "Activate in 'set A'" and "Activate in 'set B'". These would call a custom handler which would work in the way that Sean suggests. This would keep the activation withn the two Workgroup Sets independent of the Agent's status, which would probably end up being both more efficient and easier to maintain...
    Paul Simpson
    Technical Sales Systems Engineer

  6. #6
    Join Date
    Oct 2002
    Location
    Indianapolis
    Posts
    2,048
    I would probably take a different approach, and use Categories to control which agents can answer calls on a specific queue.

    So, when an agent changes status, set the Categories on the agent based on the status name.

    In one of the customization points before an agent gets selected for the interaction, set a Category on the interaction that matches the one set on the agents who should be receiving the interaction.

    That way, you don't have to worry about looking up workgroup membership and changing it (bad idea anyway - you should use Workgroup Activation instead, if you are going to do something like that).

    If the agents always go between the same sets of workgroups based on Status, you could use an IP Table to look up which workgroups an agent should be activated on when they change to a new status...but you'd also need to have to de-activate them in the previous workgroups, which is only easy if they always go between the same sets of workgroups. It's harder to look up the info on which workgroups an agent is active in, since it is not stored on the agent but on the Workgroup, so you'd have to parse through all the workgroups to figure out where an agent is active.
    George Ganahl
    Principal Education Technology Consultant

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •