Feedback

  • Contents
 

CallHistory Schema

The CallHistory table holds call-completion information for every call placed.  This table indicates who was called and the completion result of the call. 

NOTE: Do not truncate the Call History table, or set the ID seed back, without similarly altering the other attached tables (callhistory_details and callhistory_digitalhistory), as this creates duplicate "callhistory_id" entries in the callhistory_details table.

Column

Details

Description

campaignname

varchar(255), not null

The name of the Campaign.

siteid

varchar(80), not null

The name of the Outbound Dialer Server / Manual Calling Server that processed the call.

i3_identity

bigint, null

i3_identity is an integer value that uniquely identifies each row in the contact list.  Dialer manages this field for the customer. Customers may insert records that contain i3_rowid, but they cannot and should not populate i3_identity fields. Although i3_rowid is deprecated from Dialer's point of view, it was retained for backward compatibility purposes. 

When using the Follow Up Call feature, you'll see the same integer value in multiple rows - one for each additional call. To help you track each additional call, the phone numbers will appear in the corresponding phonenumber column. The label assigned to the phone in the contact record will appear in the corresponding phonenumbertype column.

i3_rowid

varchar(80), null

i3_rowid is a customer-managed field used to uniquely identify a row. i3_rowid is no longer a required field, since it was superseded by i3_identity, a Dialer-managed field.  However, i3_rowid is supported in the contact list and is propagated to the CallRecordSchedule and CallHistory tables.  i3_rowid is also available in Scripter and in policies for backwards compatibility.

callid

char(11), null

The callid number of this call attempt. For more information, see the discussion of callid in the Reporting Data Dictionary.

callidkey

char(18), null

This internal, site-unique key identifies a call in the system. It is an 18 character alphanumeric strings whose format may change from release to release, though the values will always be unique. This field is not referenced in any report, but can be used by customers to cross-reference Dialer calls with the standard call data stored in the CIC database. For more information, see the discussion of callidkey in the Reporting Data Dictionary.

wrapupcategory

varchar(80), not null

A code that generally identifies the completion status of the call.  Used to provide standardized reporting across multiple campaigns. See Wrap-up Codes and Categories.

If you create a custom wrap-up category, this column will contain a GUID that is associated with the display name of the custom wrap-up category. To match the GUID to the display name for reporting purposes, you will have to use the WrapupCategory lookup table. See WrapupCategory Table

wrapupcode

varchar(80), not null

A code that more specifically indicates the outcome of the call.  Wrap-up codes add granularity to reporting, while wrap-up Categories provide for standardized reporting across multiple campaigns. See Wrap-up Codes and Categories.

If you create a custom wrap-up code, this column will contain a GUID that is associated with the display name of the custom wrap-up category. To match the GUID to the display name for reporting purposes, you will have to use the WrapupCode lookup table. See WrapupCode Table

callingmode

tinyint, null

The value in this column identifies the Dialing Mode.

Value

Meaning

0

Non-Dialer Call

1

Predictive

2

Power

3

Preview

8

Agentless

phonenumber

varchar(50), null

The telephone number dialed for this attempt.

phonenumbertype

varchar(80), null

The customer-defined phone number type associated with the phone number dialed. This is used for reporting purposes.

When using the Follow Up Call feature, you will find the term "NULL" in the phonenumbertype column if this was an ad-hoc call where the number was manually entered.

agentid

varchar(80), null

The CIC User ID of the Agent who processed the call, as it is defined in Interaction Administrator.

calledpartyoffset

int, null

Offset in seconds used to adjust UTC times based on the called party's time zone.

odsoffset

int, not null

Offset in seconds used to adjust UTC times based on ODS's time zone. 

previewpoptimeUTC

datetime, null

In Preview mode, the time when the call record popped for the Agent to review.  This is the time that Preview call data was presented to an Agent (not the actual call time.)

callplacedtimeUTC

datetime, null

The time when the call was placed by Telephony Services.

callansweredtimeUTC

datetime, null

The time when the call was answered by the remote party or a device.

messageplaytimeUTC

datetime, null

The time that a message was played to the contact, due to the campaign type or due to the absence of available agents.

callconnectedtimeUTC

datetime, null

The time that the call was connected to the Agent.

calldisconnectedtimeUTC

datetime, null

The time when Dialer stopped tracking the call. This can occur when the call is disconnected or the call is completed upon a disposition being received from either by an agent or the system.

length

int, null

Length of the call in seconds. The length column in the Call History table does not always match the call duration. The callplacedtimeUTC and calldisconnectedtimeUTC accumulators are tracked internally by Dialer and may not match Interaction Summary information for the call. The length field is calculated from the Completed time minus the Start time. The completed time is set when the call is completed and the wrapup code is written. That happens after policy evaluations and agent finalization. The start time occurs when the call is placed. The length field can match the (Disconnected - Placed) time when the disconnect was a result of the wrapup and finalization of the interaction. This can occur if you disposition an interaction while the call is still live.

caresult

tinyint, null

See also the description of the cadetail column. This integer number that indicates the result of call analysis. Null values are allowed. The other possible values are listed below.

Value

Meaning

0

Represents an unknown call result. Call analysis could not determine what the remote party was, but the call did succeed and connect. Dialer treats this as live voice.

1

Voice detected. A human answered the call.

2

The carrier sent a SIT tone or a SIT message.

3

A Fax machine answered.

4

An Answering Machine answered the call.

5

The call failed with an ISDN Cause Code returned from the carrier.

6

Failure. The call failed in Telephony Services for some reason other than the above.

cadetail

varchar(255), null

Call Analysis results for each call are written to the CallHistory table along with the other information about the call, such as Wrap-up Codes and Categories, call id, and so forth. This allows reporting to be done not just on disposition, but also on call analysis results. This is important for customers whose call analysis is performed by Media Servers.

Two columns in CallHistory table facilitate this:

  • caresult indicates the result of call analysis.

  • cadetail provides a textual description of the call analysis result.

    The cadetail (call analysis detail) column is text field up to 255 characters in length that contains extra information that supplements the caresult value.

    For example, if caresult is 2 (SIT), cadetail would contain a description of the SIT tone/message. For a caresult of 5 (ISDN Cause Code) cadetail would contain a description of the ISDN cause code. For caresult 6 (Failure) cadetail would contain a description of the error returned from MakeCall. Null values are allowed, since some caresult codes do not generate detail information.

isabandoned

bit, null

This flag indicates whether the call was abandoned (1=Yes, 0=No). This value can be set by Dialer or by a script. See Interaction Scripter Developer Guide for details.

iscontact

bit, null

This flag indicates whether the call reached a live contact (1=Yes, 0=No). Contacts are defined in the Dialer configuration. Specifically, the "Interaction Connected to an Actual Person" checkbox in Wrap Up Categories affects the "iscontact" field.

isdetect

bit, null

Signifies whether call analysis detected that the call was answered by a person. If call analysis is turned off, the value will always be 1 (true) since those calls are treated as live voice.

isrpc

bit, null

Signifies whether the call was a right party contact.

issuccess

bit, null

Signifies whether the campaign result was achieved, governed by the "interaction was successful" setting on the wrap-up Category.

successresult

float, null

This column is populated with the value of the successresult column on the contact.

Successresult is a customer-managed column in both the ContactList and CallHistory tables. Customers can use successresult to maintain running counters, such as a money counter for example. The value of 'successresult' can be NULL when records are added or updated.

The value of successresult in a CallHistory row will contain whatever was in the successresult column of the associated contact at the time the history row was written (when the record was dispositioned).

customdata1

varchar(255), null

Provided for customer use. Not used by Dialer.

customdata2

varchar(255), null

Provided for customer use. Not used by Dialer.

campaignfilterid

smallint, null

The ID assigned to the filter that is applied to the campaign.

previewtimerinit

bit, null

This flag indicates whether a Preview call was initiated manually or automatically through a campaign configured preview timer.

  • If it is a 1, then the call was initiated automatically through a campaign configured preview timer.

  • If it is a 0, then the call was initiated manually.

  • If it is null, then the call was made using a dialing mode other than Preview.

rulegroupid

smallint, null

The ID assigned to the Rule Group that was set. You can find more details about the RuleGroupID, such as the name of the Rule Group, in the CallHistory_RuleGroup table.

callscheduletime

datetime, null

When a scheduled callback occurs, this field will show the date and time that the call was scheduled. (Based on CCS time)

More specifically, when a call results in a scheduled callback, a record is added the CallHistory table for that call and both the wrapupcategory and wrapupcode entries will contain the word Scheduled. The callscheduletime entry will be set to NULL at this point.

When the scheduled callback actually occurs, a second record will added to the CallHistory table for that call; only this time the  callscheduletime entry will show the date and time when the call was scheduled and the wrapupcategory and wrapupcode entries will contain appropriate values.

Keep in mind that the callscheduletime entry will NOT indicate when the actual call occurred - just the time that the call was scheduled to occur. If you wish to determine the elapsed time between when the call was scheduled and when the call was actually made, you will need to check the callplacedtimeUTC entry in the record.

IsAdditionalCall

bit, not null

This flag indicates whether the call is one of the additional calls made to the same contact using the Follow Up Call feature or an standard call.

  • If it is a 1, the then call was one of several additional calls made to the same contact.

  • If it is a 0, then the call was a standard call.

agentoverride

 

tinyint, null

 

If the agent chose an override option while using the Follow Up Call feature, there will be a code number in this column that indicates what type of override that occurred. To find out what type of override the code number indicates, you'll need to check the AgentComplianceOverrides table. By performing an SQL join of the CallHistory table and the AgentComplianceOverrides table, a database administrator can extract the pertinent data.

history_id number(20,0, not null

For calls that reached a contact, correlates to matching record in the Call History Details table, where time stamps for key events about the call are stored.

NOTE: The easiest way to populate the two custom fields (Customdata1 and Customdata2) can be achieved through policy behaviors. The user could use macros to populate an entry in a way that could be used after the fact.