CCH KPI Monitoring: Email Response System (ERS)

ERS and Web Forms

ERS can monitor email messages coming from any source; this includes messages generated from data entered on a web form, as web forms typically create email messages containing data from the completed form. Thus with the ERS, you can take the contents of email messages created from a web form and then use KPI Monitoring’s standard capabilities to trigger application updates, send alerts, auto-respond to the person who filled out the form, and so on.

Supported Email Systems

ERS supports all of email systems listed in the KPI Monitoring Email Account Setup option documented earlier in this manual (under KPI Monitoring Administration).

How ERS Works

Here is an overview of how ERS works:

1. You identify what email accounts KPI Monitoring will monitor for incoming messages.
2. When a new message arrives, KPI Monitoring loads its data into an internal table called “Inbox”.
3. Queries check the content of the incoming email message to see if the message meets certain criteria.
4. Events that use these queries send out alerts, auto-respond to the sender, and (if appropriate), and update application databases with the message data.
5. The key to this process is that KPI Monitoring takes each incoming message and creates a database record (in the “inbox” table) out of it. As a result, standard trigger (query) and event design functions are used to process and respond to each message.

What This Chapter Covers

This chapter covers the steps to configure KPI Monitoring to monitor incoming email and load those messages as records into the table called “Inbox”. 
Once those email records are loaded into the “inbox”, you may refer to the chapters on “Query Designing” and “Event Designing” for details on how to identify and respond to those email message records.

Create Connection for ERS Database

KPI Monitoring processes incoming email messages by loading them into a table called “Inbox” which is located in the SQL Server database called “KS_Inbox”. Connecting KPI Monitoring to this underlying SQL Server database may be done via any of the methods detailed in the Query Designing chapter of this guide (.NET database provider, OLE/DB, or ODBC).
Optimum system performance is obtained by using the SQL .NET data provider.

Identify Email Accounts to Monitor

To identify the email accounts that will be monitored for incoming messages, follow these steps:
Expand the Administrator option, select “Services” and then “Email Accounts”.
If the account you wish to monitor for incoming message is listed, click on the blue Edit button; if not, click on the “Add” button.

Create ERS Connection (Outside of KPI Monitoring)

ERS data is stored in a SQL Server database called “KS_Inbox”. As detailed earlier in this chapter you’ll need to create a connection to that database using either a .NET data provider (preferred connection method), ODBC, or OLE/DB in order to allow KS to monitor and respond to incoming emails.

Create ERS Application (Inside KPI Monitoring)

ERS queries and events must be stored within their own application in KPI Monitoring. To configure this, follow these steps:

1. Log into KPI Monitoring and expand your list of application events.  If a branch for the Email Response System exists, click on it and view its “Properties”.  If an ERS branch does not exist, click on the “New App” button and create an application called “Email Response System” or simply “ERS”.
2. Select the connection that points at the inbox database and be sure to supply the required credentials.
3. Save and close your work.

Inbox Queries

ERS queries retrieve data from the inbox table. This table contains both “loadable” fields (detailed earlier in this chapter) as well as pre-loaded fields that KPI Monitoring populates with details from incoming messages. 
The following list describes all the inbox pre-loaded fields. A query may retrieve and use data from any combination of loadable and pre-loaded data fields. Please do not modify or remove any of the following fields from the Inbox database.

Inbox Events

Inbox events are created just like standard application events. However, you might decide that you’d like to link an incoming email message to a corresponding contact record within a customer database. This would let you:

• Identify the corresponding account manager and alert them
• Update the customer’s record with the details of the incoming message
• Create a record (such as a support ticket) and link that ticket to the customer
• Identify if the sender is not already in your customer database

Linking Mail Messages to Client Records

You can link an incoming email message to a customer record in two ways:

1. Using two queries in one event
2. Using a Visual Basic script or a web service call

Although VB scripts and web service calls give you complete control and flexibility in terms of creating database records based on receipt of an incoming email, both methods require programming expertise. The use of two queries requires no programming knowledge.

When you use two queries in an inbox event, the first query retrieves the email records, and the second query links those records to your customer database. 
This requires identifying a field in the inbox record that matches with a piece of data from the customer record. This might be the sender’s email address (stored in the “from_root” column in the Inbox table), but could also be any other field in the incoming message that corresponds to a matching field in your customer database (such as a customer’s “account number”).

Using a field such as the sender’s email address to match to a customer’s record in an application database, your two queries would work as follows:

• Query #1 (retrieving inbox records) would include the linking field (i.e., the sender’s address, “from_root”) as one of the fields in the query.
• Query #2 (retrieving customer info) would have a filter that compares the email address in the customer application (e.g., “customer.mail”) to the customized name of the inbox sender address field (e.g., “{from_root}”).

This is illustrated in the following:

 MATCHING EMAIL ADDRESS TO DATABASE RECORD

An event that uses two queries in this manner will trigger only if the sender’s address is also found in the customer database. Once a match is found, all of the fields of data from both queries may be used in alert messages and in workflow actions. 
(And, although the above scenario identifies message senders who exist in a customer database, you could construct a similar event where your second query looks for no matches to your customer database. This would identify a new client or prospect.)

Alerts & Actions

In response to an inbox event, KPI Monitoring can send messages to:

• The salesperson and/or support person associated with an account
• The sender of the incoming mail message
• Other people related to the incoming message (such as “cc” names)

These messages can include all standard content associated with a database event. Here is an example of a message that could send back to a person who logged a support question via email:

Hello {from_name},
This is to confirm our receipt of your email sent on {sent_dt} to {to_names}.
We will contact you shortly when we have an answer for you.
Thank You,
Support Team

KPI Monitoring can also execute workflow actions because of a triggered inbox event. One common use of an inbox action is to have an event take information from an incoming email and pass that into a VB script or web service call to create or update records within an underlying application database.

Using Email for Report Requests

You can use ERS to allow users, partners, or clients to request and receive forms, documents, or reports. Consider the scenario where an organization has staff who need to need to run reports, but currently must ask their IT department to run the reports for them.
Using the ERS module, an organization could configure a mailbox called “report_requests” and whenever a staff member needs a report, they could send a message to that account. The message could include the name of the report to run and even the selection criteria for that report.
When such a message is emailed, KPI Monitoring receives it, uses a query to determine which report is being requested, and then runs the report and emails it back to the requester. All done automatically, without human intervention.

Inbox Event Schedule

Since you want KPI Monitoring to respond to incoming mail messages as soon as they are received, all inbox events should use a frequency of “When Email Arrives.”

Inbox Events in the Monitor

To monitor the status of inbox events, use the Monitor options. Although inbox events turn into standard application events, there is an additional branch called Email Response.

The Email Response branch lets you check to see what mail messages have been received (and logged) into the inbox database.
Once an incoming message has been received and loaded into the inbox database, you may use the standard application event and delivery branches of the Monitor to check to see if the inbox event was triggered, who was notified, what applications were updated, and so on.