Guest

Cisco Other Optoelectronic Products

CIM: Use Alarm Workflow to Process Activities from the nIPTA Queue

Techzone Article content

Document ID: 116225

Updated: Jul 31, 2013

Contributed by Stephan Hartman, Cisco TAC Engineer.

   Print

Introduction

This document describes the method to create an alarm workflow to process the activities from the Non-ICM Picks the Agent (nIPTA) queue.

Components Used

The information in this document is based on CIM Release 4.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

When e-mail activities are sent to the nIPTA queue, it might be necessary to recover those activities so they can be processed.  There are two methods available to process this:

  1. Move the activities manually.In order to do this, you must have a nIPTA skilled agent monitor the nIPTA queue and/or receive notifications when items enter that queue. The nIPTA agent can then transfer to the agent?s or queue?s to be processed.  This nIPTA agent must onlybe skilled in nIPTA skill groups.
  2. Set up an Alarm Workflow. In order to do this, create an Alarm Workflow against the nIPTA queue and have it set up to run on a specific schedule or at a single designated time. This allows the system to process the e-mails through External Agent Assignment Service (EAAS) and Unified Contact Center Enterprise (UCCE) again.

Create an Alarm Workflow

These steps are intended to have activities processed through Integrated Queues that have previously been directed to the nIPTA queue. There are two important things to remember when you attempt to accomplish this task.

  • Know which Integrated (mapped) Queues that you want to include.
  • Know which Alias(s) configured within our CIM environment is mapped to each queue.

These two items are important since the alarm workflow uses the alias to which the e-mail was sent in order to determine which queue to redirect the activity towards. This is the original queue which should have been hit if the routing failure had not occurred.

  1. In order to create an Alarm workflow, select the New icon in the List panel and create a name for the workflow.

    Figure 1a: Create a New Workflow

  2. Once the workflow is created, it is listed in the List panel. In order to add an instruction, select the Diagram tab.

    Figure 2a: Create a New Workflow Diagram

     

  3. In order to configure the workflow, add a Start node into the diagram.  After you place the node, the Add Start Node dialog box appears.   For this workflow example, select your Inbound_Email_nIPTA_SG_Service, or the name of your specific nIPTA queue.

    Figure 3a: Start Node Configuration

      

  4. Once the nIPTA queue is selected, configure the Schedule when the workflow should run.  This workflow can be run once each time it is necessary. In order to run the workflow, click the The workflow should be run once at radio button, and then change the time each time you wish to have it run.  For this example, this node is filled out with the workflow to run every 5 minutes all day. This continuously sweeps the nIPTA queue and reroutes activities back to EAAS.

    Figure 4a: Configure a Start Node Schedule<

     

  5. Once your start node is in place, configure an Alarm node, a Branch node and Queue nodes.  In order to build a Branch node, you must add all the queues for the Branch node rules. This directs the activities, so create the workflow from right to left.  Select the Queuenode and place a node for each Queue within the diagram of the workflow.  Each time you put the node option down, a Select Queue dialog box is displayed, and it is necessary to choose which queue the node represents.
    1. Queue the nodes.

       

    2. Choose the Queue Dialog Box.

       

  6. Once the queue nodes are in place, choose Add new Branch node.  Once the Branch node is placed, the Branch Rule Configuration dialog box opens.

    Figure 6a: Select the Branch Node.

     

  7. When the Branch Node Configuration dialog box opens, you must to configure one rule per queue (or branch) where the node maps.

    Note: A branch node can map to other items as well, such as directly to a specific user. For this example, it is mapped to integrated queues.

    1. The Branch Rule Configuration dialog Box appears.

       

    2. Name and designate the rule conditions and choose Enter.

      For this type of Alarm workflow, name each of your rules. Next, highlight the rule and configure the conditions. The conditions should be set for:

      Object : e-mail

      Attribute : To e-mail address

      Operator : ==

      Value : <alias that the e-mail originally was sent to goes here>*

      • If you are uncertain of the alias that the e-mail was originally directed to, you can execute the following query and replace the activity ID of a specific email in the place of ?####?; select recv_email_address, * from egml_email where activity_id = ####.
      • The additional point is that the e-mail alias indicated here is the one mapped to the queue(s) indicated in the previous step.

       

    3. Configure and map TRUE conditions to the queues in the Branch Node Configuration.

      Once you have configured the rule, you must indicate what branch (queue) to use in the event that the rule is evaluated as TRUE.

       

      Verify the This rule is TRUE under the following conditions radio button is chosen. Click [?] to select a target.  Next, the Select Target dialog box appears to allow you to drill down to the proper queue for this rule.

      Note: If the queue nodes in this workflow are not placed first, there will be no content in this list.  The queues indicated in the workflow determine what is displayed here. Repeat for the other queues.

    4. Configure and map the FALSE condition in the Branch Node Configuration.

      Once you have set the TRUE option for your rule, you must set up a FALSE option.  In this example, the Exception queue is indicated as this path. Alternatively, you can set it up for any other path, another integrated queue, a standalone queue, or a specific User. This depends on your business and how you prefer to handle these items.  This option catches any items that do not match the rules in the branch node. 

      Repeat the Rule configuration for each branch, and repeat the exception queue (or false selection) for each one.  When you have configured the node completely, the lines connecting the branch node to your queues complete automatically based on your rule configuration. Your node appears:

  8. The last item you need to configure within this workflow is an Alarm node.  Pull down and place a new Alarm node into the workflow diagram.  The Alarm Node Configuration dialog box opens.
    1. Select, place, and configure an Alarm Node within your Workflow Diagram.

    2. The Alarm Rule Configuration Screen appears. Configure the Condition tab.

      On the Alarm Rule Configuration screen, there are two tabs that need to be configured: a Conditions tab and a True tab.

       

      On the CONDITIONS tab, you only need to identify the Age minutes. 

      CONDITION 1

      Object

      Activity

      Attribute

      Age minutes

      Operator

      Value

      1

    3. The Alarm Rule Configuration Screen appears. Configure the True option on the Basic tab.

      On the True tab, complete these configurations in order to create a filter and select the objects for the filter from within the Basic and Advanced sub tabs.

      In the Action section in the top pane, select the drop-down list in order to create a filter with Activity as the object that the filter will be run against.  The bottom pane is populated with the options to select criteria for the filter.  On the basic tab, ensure the subject does not contain the word Undeliverable.  This filters out any items with an Activity_Sub_Type of 4 and 5 (e-mails that match a configured Delivery Exception and are not be processed by EAAS). 

      Note: If you do not run this workflow often, or you find there are many e-mails in the nIPTA queue that must be processed, it is advisable to determine another filter option such as Created On. This allows you to control the number of e-mails that are processed back into queues.  You should research the numbers of e-mails waiting to be processed, and make a determination based on your environment and agents available to process these items. That decision is specific to your environment.

       

    4. The Alarm Rule Configuration Screen, Configuring the True Option; Advanced Tab.

      On the Advanced tab, choose Email-Generalfor the Activity Sub Type. This ensures that only items with an Activity_Sub_Type = 1 are selected.  This is a requirement since the EAAS process will ONLY send route requests (NEW_TASK Requests) to UCCE to process if they are this sub type.  Any other sub types are not processed.

  9. When completed, your Alarm Workflow appears. This may vary based on the number of queues you have built into it. This process and document are intended for integrated (mapped) UCCE queues.

    Figure 9a: The Completed Alarm Workflow Diagram

     

    In the Active field, choose Yes in order to make the workflow active.

     

 

Related Information

Updated: Jul 31, 2013
Document ID: 116225