Exception Queue Email

From DocWiki

Scenario Setup

Agent PC

1. Send five emails with subject lines matching Delivery Exceptions
   1. Abwesenheitsnotiz
   2. AutoReply
   3. Delivery-Report
   4. Nondeliverable
   5. system
2. Use two integrated agents for this scenario: goofy and mmouse

Throughout the life of the mail, use the below query to follow the activity:

select top(10) egpl_routing_queue.queue_name, * from egpl_casemgmt_activity LEFT OUTER JOIN egpl_routing_queue on egpl_casemgmt_activity.queue_id = egpl_routing_queue.queue_id order by activity_id desc

Problem Statement

Email is sent to alias, but UCCE Script Editor shows no evidence of email ever entering the queue.

Where is it?

Query the eGActiveDB and see the activity come in as activity_status 3000 and activity_sub_status 3100. That's no different from other mails coming in. The key is the activity_sub_type: it is 4 instead of the usual 1.

EAAS will not pick up an activity for routing if its activity_sub_type is anything other than 1. So, this email is going to be routed to the Exception Queue.

If we look at the subject or sender's address we can match to our list of delivery exceptions.

The activity_status and activity_sub_status will remain 4000/4100 until a supervisor/admin/etc with access to the Exception Queue logs in and completes the activity. Even if these activities are transferred to an IPTA queue, they will not be picked up by EAAS for UCCE routing due to the activity_sub_type != 1.

So how do we get to it?

It is not directly possible to provide an Integrated Agent with Permissions on a Standalone Queue such as the Exception Queue. In the Queue Properties, only Standalone Agents are shown.

Picking with Agent & Supervisor roles

Let's first provide an Integrated user with both Agent and Supervisor roles.

1. Log in to the PA console and assign these roles, then log in as that agent.
2. Once in the Agent Console, notice that the Supervisor role has given your agent the ability to "Pick."
3. Try to Pick the email from the Exception Queue.

You can see queues, but not the Exception Queue.

Picking with Agent, Supervisor, & Administrator roles

For Integrated Agents, you must have the Administrator User Role to be able to access the Exception Queue.

1. Log out of the agent console and log back in as PA again.
2. Assign the Administrator role to your integrated agent, then log in as that agent.
3. Click the "Pick" button again to take the activity from Exception Queue.

Queue Load = 0

Run the following query on the eGActiveDB to check for any activities in queues other than the Exception Queue that have activity_sub_type != 1. It should return 0 results.

select top(10) egpl_routing_queue.queue_name, * from egpl_casemgmt_activity LEFT OUTER JOIN egpl_routing_queue on egpl_casemgmt_activity.queue_id = egpl_routing_queue.queue_id where egpl_casemgmt_activity.activity_sub_type != '1' and egpl_casemgmt_activity.activity_status = '4000' and egpl_casemgmt_activity.activity_sub_status != '4107' and egpl_casemgmt_activity.QUEUE_ID != '21' order by egpl_casemgmt_activity.activity_id desc

Queue Load + 1

Transfer the activity to your integrated queue, then run the query again. The email will be in the Integrated Queue with activity_sub_status 4105, but will never be picked up because activity_sub_type is still !=1.

On a second agent desktop, log in as your non-administrator integrated agent and go ready to verify the activity will not be routed to you.

Queue Load = 1

Use the integrated administrator to try to transfer another mail to the IPTA queue. This can be any mail; it does not have to be from Exception Queue. You will see now that the Integrated Queue's Email Load is 1 due to the previously-transferred email, which will never be picked up. Complete the transfer.

Repeat the above Pick-and-transfer to have five emails from the Exception Queue in the Integrated Queue with activity_sub_type != 1.

Note: If the Queue Load is >0 but agents don't receive the mails, it will lead to reports of "EIM says emails are in queue, but none are being routed to my agents!"

EIM is functioning properly, but it will not seem that way to agents/supervisors!

Cleanup

We have to get rid of that email. Let's try to pick it out of the queue again. No luck - it will not appear here because you cannot pick from integrated queues.

We'll have to update it from the database. From the above steps, we know that the activity_id is 1181. We have a few options:

Option 1: Route to agents

We can choose to ignore the Delivery Exception and reset the email to a routable activity.

UPDATE egpl_casemgmt_activity 
SET activity_sub_type='1', activity_sub_status='4100'
WHERE ACTIVITY_ID='1181'

The activity will be routed to an agent.

Option 2: Move back to the Exception Queue

This will resolve the issue of emails showing in an integrated queue's Email Load, but will still leave the activity sitting in the Exception Queue. See next section for the ideal way of handling these activities.

Verify your Email Load once again.

Let's see how our activity is now different from other Delivery Exception activities now that we've put it in an Integrated queue.

select top(10) egpl_routing_queue.queue_name, * from egpl_casemgmt_activity LEFT OUTER JOIN egpl_routing_queue on egpl_casemgmt_activity.queue_id = egpl_routing_queue.queue_id where egpl_casemgmt_activity.activity_sub_type != '1' and egpl_casemgmt_activity.activity_status = '4000' and egpl_casemgmt_activity.activity_sub_status != '4107' order by egpl_casemgmt_activity.activity_id desc

Note the different Queue_ID. Let's check the Queue_ID of the Exception Queue using

select * from egpl_routing_queue

So to move the email to Queue_ID 21, we can use the following query:

UPDATE egpl_casemgmt_activity 
SET queue_id = '21'
WHERE ACTIVITY_ID='1181'

Our integrated queue's Email Load is back to 0, and the activity is once again sitting in the Exception Queue waiting for someone to complete it.

Automatic Handling

How can we automatically handle delivery exceptions? The system would ideally complete these activities in the Exception Queue before anyone transferred them to other queues. This can be accomplished using an Alarm Workflow that runs periodically and automatically completes activities with activity_sub_type 4 or 5.

What is an Alarm Workflow?

Alarm workflows can process activities in the system and perform actions such as notifications, escalations, reassignments, etc. depending on the specified conditions. Each deployment comes with an out-of-the-box "Exception Queue Alarm Workflow" that notifies administrators of activities pending in the exception queue.

Create a new Alarm Workflow

Log in as your partition administrator and navigate to Administration Console > Departments > Service > Workflow > Workflows > Alarm

Create a new Workflow and name it "Delivery Exceptions Alarm Workflow"

Add a Start node.

Add an Alarm node.

Name it "Exception Queue Incomplete"

Look for activities with criteria:

1. Not completed
2. Queue name contains "Exception"
3. Not activity_sub_type 1

Note that activity_sub_type 1 corresponds to General Email. We want to exclude these from the Alarm.

Add a Completion node. You will need to reference this when you create the next node.

Add a Branch Node.

Name it "Delivery Exception"

Create a rule and name it "Delivery Exception Rule" Note that activity_sub_type 4 and 5 correspond to Permanent and Temporary Undeliverable.

The finished Alarm Workflow will look like the below:

Verify the Process and Instance are running.

Verify it worked in the Alarm Rules log

2011-05-16 20:10:17.335 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.AlarmRuleInstance <@> doAlarmWork <@> Executing alarm workflow Exception Queue Alarm Workflow <@> 
2011-05-16 20:10:17.335 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.AlarmEngine <@> applyWorkflow( CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId ) <@> Executing Workflow:Exception Queue Alarm Workflow <@> 
2011-05-16 20:10:17.335 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1014 - Activity Id: -1 <@> 
2011-05-16 20:10:17.335 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.AlarmRule <@> apply( RuleContext oContext ) <@> Alarm Rule Evaluated: Send Email Notification <@> 
2011-05-16 20:10:17.335 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Condition String : activity_sub_status == 3800  <@> 
2011-05-16 20:10:17.335 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Where Clause: activity_sub_status = 3800  <@> 
2011-05-16 20:10:17.366 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.AlarmRuleInstance <@> doAlarmWork <@> Executing alarm workflow Delivery Exceptions Alarm Workflow<@> 
2011-05-16 20:10:17.366 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.AlarmEngine <@> applyWorkflow( CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId ) <@> Executing Workflow:Delivery Exceptions <@> 
2011-05-16 20:10:17.366 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1026 - Activity Id: -1 <@> 
2011-05-16 20:10:17.366 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.AlarmRule <@> apply( RuleContext oContext ) <@> Alarm Rule Evaluated: Exception Queue Incomplete, <@> 
2011-05-16 20:10:17.366 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Condition String : activity_status != 9000  <@> 
2011-05-16 20:10:17.366 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Where Clause:  ( activity_status IS NULL OR activity_status != 9000  )  <@> 
2011-05-16 20:10:17.523 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.AlarmRule <@> apply( RuleContext oContext ) <@>  True action executed for the Rule: Exception Queue Incomplete, <@> 
2011-05-16 20:10:17.523 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.FilterAction <@> execute(RuleContext oContext) <@> Executing Filter Id:1007 <@> 
2011-05-16 20:10:17.835 GMT-0400 <@> INFO <@> [47:AlarmRuleInstance id : 989] <@> ProcessId:3652 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> applyFilter(long filterId) <@> Activity Ids after applying Filter are: 1000,1001,1042,1043,1044,1069,1070,1071,1147,1127,1093,1181, <@> 

Audit Trail

Call Flow

Resolution

This scenario focused on Exception Queue emails, specifically those triggering Delivery Exceptions. We learned what is necessary to handle these emails, and how they can impact reporting if managed improperly.