Troubleshoot Emails Going to Default Exception Queue in ECE

Introduction

This document describes how to isolate and fix issues related to emails routed to default exception queue in Cisco Enterprise Chat and Email (ECE).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Cisco Unified Contact Center Enterprise  (UCCE) Release 12.6.X
• Cisco Packaged Contact Center Enterprise  (PCCE) Release 12.6.X
• Enterprise Chat and Email (ECE) Release 12.6.X

Components Used

The information in this document is based on these software and hardware versions:

• UCCE Release 12.6.2
• Enterprise Chat and Email (ECE) 12.6.1

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, ensure that you understand the potential impact of any command.

Background Information

Queues hold incoming customer service activities such as emails and chat sessions that are waiting to be assigned to agents.

ECE comes equipped with a Default Exception Queue already available. More queues can be added to the application by importing MRDs. This creates a Unified CCE type of queue and the routing of activities from this queue is done by Unified CCE.

Exception Queue by default, an exception queue is created in every department. Activities are routed to the exception queue when:

• There are no active inbound workflows in the department.
•  A workflow faces an error while processing activities.
•  The queue used in a workflow is made inactive. All the activities coming to the inactive queue are routed to the exception queue.
•  Emails are bounced back.
•  A new_task_failure message is returned by Unified CCE, once EAAS receives the New_Task_Failure response 3 times post first failure response (that is, first failure response + 3 retry attempt) then EAAS routes such activities to the Exception queue.
•  If a connection is lost with the Cisco routing system; for example, if the MR PIM machine temporarily shuts down or restarts.

Procedure

This document shows the steps required to troubleshoot and isolate issues with inbound emails that were routed to default exception queue. It is a procedural checklist that helps engineers in order to isolate or resolve relevant issues faster.

To effectively troubleshoot ECE, you are going to divide the flow into three legs. This is similar to how you would approach a voice call flow.  These three legs are as follows:

1. Ingress Leg – Getting from the customer to ECE.
2. Treatment Leg – Getting from ECE to UCCE.
3. Agent Leg – Connecting the customer with an agent.

Verification

This document focuses mainly on Treatment Leg by verifying these points:

Workflow Engine: Verify Process and Instance Status

Note: Verify EAAS and EAMS processes if they are active, and they must be active.

Verify Email Channel Agent Availability

There are many ways to verify if the agents are logged in but you can utilize rttest.

## The agent does not log in.

rttest: agent_status /agent 5001 
 domain: Email_MRD (5001), state = [off], 239 secs
 C off Inbound_SG (5011, periph# 3)
 off agent_peripheral.Email_MRD.14828 (5008, periph# 58660)
 domain: OutboundEmail_MRD (5002), state = [off], 239 secs
 C off Outbound_SG (5012, periph# 4)
 off agent_peripheral.OutboundE.30541 (5009, periph# 74372)


## The agent does log in to ECE but the agent is not marked as available for email channel.

domain: Email_MRD (5001), state = [nr-0:1[0],R], 9 secs
 CL nr Inbound_SG (5011, periph# 3)
 L nr agent_peripheral.Email_MRD.14828 (5008, periph# 58660)
 domain: OutboundEmail_MRD (5002), state = [nr-0:1[0],R], 9 secs
 CL nr Outbound_SG (5012, periph# 4)
 L nr agent_peripheral.OutboundE.30541 (5009, periph# 74372)


## The agent does log in to ECE as well as the agent is marked as available for email channel.

 domain: Email_MRD (5001), state = [na-0:1[0],RA], 4 secs
 CL na Inbound_SG (5011, periph# 3)
 L na agent_peripheral.Email_MRD.14828 (5008, periph# 58660)
 domain: OutboundEmail_MRD (5002), state = [na-0:1[0],RA], 4 secs
 CL na Outbound_SG (5012, periph# 4)
 L na agent_peripheral.OutboundE.30541 (5009, periph# 74372)

## Here you can find more explanation for rttest output regarding agent's availability.

off- NotLoggedIn
nr - NotReady
na - NotActive
0:1 – AciteTasks(0):ConcurentTaskLimit(1)
RA - R is routable (if set), A indicated the router considers the agent available for new work in this domain.

Verify Workflow Status

You must see the workflow name in the audit page of the activity as you see it in the image.

And then, you can verify if that worflow is being active. Navigate to service> workflow.

Workflow Activity Processing Validation

Rules-process logs at INFO level can give you useful information in order to isolate and troubleshoot the relevant issues.In order to ensure the proper trace level, navigate to Partition > System Resources > rules process.

Ensure the Maximum Trace Level is set to 4-Info.

This workflow demonstrates how to manage emails coming into a company. First, a service level is set for the emails. Then, based on branch condition, it routes the activity to the respective queue.

At start node, you can map the alias to the inbound workflow. In this example, it is [email protected].

Service levels allow you to set up response time expectations for incoming customer service interactions. Service level can be defined for cases and all activities other than chat activities. Once defined, they are used in workflows to influence activity routing. This example explains SLA node Lab SLA that is associated with the ruleLab SLA Rule that specifies all incoming emails to i[email protected], specifically, which is evaluated and true actions executed since the incoming email was to [email protected].

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1032 - Activity Id: 6081 <@>
2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: Lab SLA - Activity Id: 6081 <@>
2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@> Rule Evaluated: Lab SLA Rule - Activity Id: 6081 <@>
2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.ComparisonCondition <@> evaluate() <@>  Condition Attribute is : egml_email.to_or_cc_email_address - Comparing: [Ljava.lang.String;@6a6230a5 == [email protected]c - Activity Id: 6081 <@>
2024-06-06 15:50:49.202 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@>  True action executed for the Rule: Lab SLA Rule - Activity Id: 6081 <@>

Branch node is a decision point where you decide what kind of work is to be routed to which resource. Using rules, you can automatically route work to the resources capable of handling it. Activities can be routed to users, queues, departments, or another workflow. This example explains branch node TAC Branch that associated with the rule TAC Rule which specifies all incoming emails with title that contains SR#, specifically, which is evaluated and true actions executed since the incoming email with title SR#123456789.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1033 - Activity Id: 6081 <@>
2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: TAC Branch - Activity Id: 6081 <@>
2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@> Rule Evaluated: TAC Rule - Activity Id: 6081 <@>
2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.ComparisonCondition <@> evaluate() <@>  Condition Attribute is : egml_email.subject - Comparing: SR#123456789 contains SR# - Activity Id: 6081 <@>
2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@>  True action executed for the Rule: TAC Rule - Activity Id: 6081 <@>

This log line explains that activity moved to queue as per workflow design.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> routeActivity() <@> Activity moved to Queue Id: 1008 - Activity Id: 6081 - approval_type configured for the queue:  <@>

The same example explains branch node, TAC Branch, that is associated with the TAC Rule which specifies all incoming emails with title that contains SR# specifically which is evaluated, and False action executed for the Rule since the incoming email was with title that contains case#123456789, and it did not contain any SR# in the title. Based on that, activity was not processed and moved to default exception queue.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1033 - Activity Id: 6086 <@>
2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: TAC Branch - Activity Id: 6086 <@>
2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@> Rule Evaluated: TAC Rule - Activity Id: 6086 <@>
2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.ComparisonCondition <@> evaluate() <@>  Condition Attribute is : egml_email.subject - Comparing: case#123456789 contains SR# - Activity Id: 6086 <@>
2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@>  False action executed for the Rule: TAC Rule - Activity Id: 6086 <@>

2024-06-06 16:14:20.535 GMT+0000 <@> ERROR <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.BPRulesInstance <@> checkAndMoveStuckActivitiesToException() <@> Activity is not processed, moving to exception queue :  Property = ActivityId & value = 6086
  Property = CaseId & value = 6052
  Property = DepartmentId & value = 999
  Property = ActivityType & value = 1
  Property = ActivityMode & value = 100
  Property = ActivitySubType & value = 1
  Property = ActivityStatus & value = 4000
  Property = ActivitySubStatus & value = 4100
  Property = ActivityPriority & value = 0
  Property = DateCreated & value = 2024-06-06 16:14:09
  Property = CreatedBy & value = 12
  Property = DateModified & value = 2024-06-06 16:14:20
  Property = DueDate & value = 06/06/2024 16:24:09

Tip: If the activity is routed to exception queue before sending New_task, you need to focus on workflow configuration and workflow rules, and If the activity is routed to exception queue after sending New_task, you need to focus in EAAS process .

No Active Inbound Workflows in the Department Verification

In this example, it shows the difference from logs perspective when there is inbound active workflow compared to the case when there are no active workflows.

Sales Department is configured with active Sales Inbound WF workflow, as you can see, the activity routed to the queue normally after inbound workflow triggered.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-08-08 18:02:05.323 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow: Sales Inbound WF - Activity Id: 6139 <@> 
2024-08-08 18:02:05.323 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: Start - Activity Id: 6139 <@> 
2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1043 - Activity Id: 6139 <@> 
2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: Sales Queue - Activity Id: 6139 <@> 
2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to external queue: 1023 - Activity Id: 6139 <@> 
2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> routeActivity() <@> Activity moved to Queue Id: 1023 - Activity Id: 6139 - approval_type configured for the queue:  <@>  

On the other hand, if there is no any active inbound workfkow, ECE triggers Finish Workflow. This workflow is executed if no defined inbound email workflow exists for the department.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow: Finish Workflow - Activity Id: 6140 <@> 
2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Finished execution of Workflow: Finish Workflow - Activity Id: 6140. Time taken = 0 seconds. <@> 
2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> doDeferredActions() <@> doDeferredActions Started - Activity Id: 6140 <@> 
2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> doDeferredActions() <@> OutBound Activity=false OutBound Rule Applied=false - Activity Id: 6140 <@> 
2024-08-08 18:14:35.858 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> doDeferredActions() <@> doDeferredAction completed for - Activity Id:   6140 <@> 
2024-08-08 18:14:35.867 GMT+0000 <@> ERROR <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.BPRulesInstance <@> checkAndMoveStuckActivitiesToException() <@> Activity is not processed, moving to exception queue :  Property = ActivityId & value = 6140
  Property = CaseId & value = 6086
  Property = DepartmentId & value = 1002  

Configure and Troubleshoot Alarm Workflows

Alarm workflow is more practical when there are huge numbers of emails in the default exception queue. Alarm workflow is configured to send notifications when activities are routed to the exception queue because of workflow errors encountered while processing activities.

You can complete emails activities in default exception queue in alarm workflow as you see in this example. This workflow checks for email activities in the default exception queue that are about to be due in 30 minutes to route them back to the TAC queue. You have to avoid all activities to be routed back to the TAC queue. Configure this flow: Start > Alarm > TAC Queue.

Note: Alarms rules logs at INFO level provides useful information in order to isolate and troubleshoot the relevant issues. In order to ensure the proper trace level, navigate to Partition > System Resources > alarm-rules process.

From start node, you must select default exception queue.

There is a schedule tab where you can configure that alarm workflow. In this example, it has been triggered once at a certain time.

In alarm rule configuration condition, you must configure what conditions match your specific business need. For this case, it has been configured for email activities that are in default exception queue, which their SLA are still not lost for more than 30 minutes.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_alarm-rules-process

2024-07-17 16:37:23.303 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.AlarmEngine <@> applyWorkflow( CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId ) <@> Executing Workflow item: TAC Case Alarm <@> 
2024-07-17 16:37:23.303 GMT+0000 <@> INFO <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.AlarmRule <@> apply( RuleContext oContext ) <@> Alarm Rule Evaluated: Alarm 7__RN_S__ <@> 
....
2024-07-17 16:37:23.307 GMT+0000 <@> PERF <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.DataAccess <@> executeSelect() <@> Executing query: calendar:get_business_date   Time taken: 4 <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> buildWhereClause(List oConditions) <@> sAttribute : 0 :  DUE_DATE  <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> INFO <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Condition String : mins_tilldue >= 30  <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> INFO <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Where Clause:  DUE_DATE  >= '07/17/2024 17:07:23'  <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> getAssociationDetails() <@> Number of Associations returned from cache:[21_4] for alarm workflow id: 1029 <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.QueryProcessor <@> getQuery() <@> Getting static query detail for query name =   rules:get_activities_for_alarm <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.ConnectionPoolMap <@> getPoolName(CallerContext context, String dsName) <@> Trying to get pool name for database and partition id =  customer_db 1  <@> 
2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.QueryProcessor <@> getQuery() <@> Now build the complete query. query set name =   rules:get_activities_for_alarm <@> 
2024-07-17 16:37:23.308 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.StaticQuery <@> preProcess() <@> query -> rules:get_activities_for_alarm, Object passed is   where_clause =  DUE_DATE  >= '07/17/2024 17:07:23'  : Type = java.lang.String
  workflow_id = 1029 : Type = java.lang.Long

Also, in alarm configuration true condition, you have to be more specific for those emails that have be routed from default exception queue to TAC queue to avoid having unnecessary emails routed to agent and then wasting their time. In this example, the subject condition is specified if it contains case instead of SR as specified in inbound workflow, so emails are routed again to TAC queue.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_alarm-rules-process

2024-07-17 16:37:23.366 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.StaticQuery <@> preProcess() <@> query -> casemgmt::sub_search_activity:mssql, Object passed is   casewhereclause = null
  classwhereclause = null
  deptwhereclause = ( egpl_department.department_name = N'Service' )  : Type = java.lang.String
  caseownerwhereclause = null
  contactpointemailwhereclause = null
  emailattachmentdatawhereclause = null
  userwhereclause = null
  emaildatawhereclause = null
  toemailaddresswhereclause = null
  custdeptwhereclause = null
  ccemailaddresswhereclause = null
  contactpointwhereclause = null
  customerattributeswhereclause = null
  whereclause = ( egpl_casemgmt_activity.subject like N'%case%' ESCAPE '\' )  : Type = java.lang.String
  contactpointsocialwhereclause = null
  routingnodewhereclause = null
  contactpersonwhereclause = null
  emailwhereclause = null
  customerwhereclause = null
  contactpointpostalwhereclause = null

Note: Restart Cisco service on ECE to have the configured alarm is usually not required. However, in some cases, if you face issues related to that alarm workflow, it is not triggered, then restart Cisco service on ECE. That sometimes helps to get it triggered.

Finally, you see here in these images how the activity was routed from the default exception queue to the available agent in TAC queue after the configured workflow has been triggered.

Now, the agents are able to see the activities with subject contains case# instead of SR#.