Understanding inContact Workforce Optimization Error Messages

Error Message Overview

inContact WFO can be configured to notify you when issues require your attention. Issues are logged according to severity, and you can choose the level at which notifications are sent.

This topic is designed to help you understand these notifications and take appropriate action. Many issues can be resolved without a call to inContact WFO Support, and following these guidelines should help you achieve the fastest resolution to any issues that arise. If you need to contact Support, you will be better able to provide critical information to your support engineer.

This topic provides general guidance, and is not meant to define the scope and severity of issues you may experience. Every inContact WFO implementation is different. For example, if you have multiple screen recording servers, and one fails, the impact will be less than for a customer who has a single screen recording server.

For detailed information on configuring log levels and alerts, see the Logging & Alerts Overview in online help. For additional information regarding issue scope and severity, refer to guidelines provided by inContact WFO Support. To learn more about redundancy and resiliency in inContact WFO, contact your account representative.

How Can This Topic Help?

Step One

Review the sample emails in the Anatomy of an inContact WFO Alert section to become familiar with the way alerts are structured.

Step Two

When you receive an email alert from your inContact WFO system, determine which application sent the message. Then review the Details: Hybrid Services or Details: Premises Services topic to see how that service affects your system.

Step Three

Check the Logging Type in the email alert. Then look at the type in the Details: Logging Types topic and take the appropriate action.

Anatomy of an inContact WFO Alert

Email alerts sent by inContact WFO pull information directly from the application logs and can be a bit challenging if you are not used to reading log data. Consider the following examples and explanations from Premises systems.

This example contains the following information:

  • Date — The date and time the log entry was created.
  • Application — The module or component within inContact WFO that generated the log entry. In this case, the module was an API Server service named CCAPISERVER1. For more information, see Details: Premises Services.
  • Logging Type — The severity level of the event. In this case, the level was Debug. For more information, see Details: Logging Types.
  • Alarm ID — This field is not currently used by inContact WFO; you may disregard it.
  • Data — Description of the actual event. In this case, the state of the application changed to "Reconnecting."
  • Diagnosis Data — This section provides details regarding the status of the server at the time the event occurred. For example, you can see the name of the logged-in user, disk usage, and so forth. This may or may not be useful, depending on the type of event.

In this example, a Web Media Server service named CC_WebMediaServer generated a Debug level log entry at 1:45 PM on April 27, 2015, when it reloaded an encryption key.

In this example, a CTI Core service named CC_CTICore1r generated a License level log entry at 6:45:28 AM on June 6, 2015. The module was unable to monitor device 5736 because there were no Avaya TSAPI licenses available. This error would only be seen in an Avaya TSAPI environment.