- Scenario 1: The UK number +44 (0)020 7551 8700 is in the contact list as +44 20 7551 8700.
- Result: This number can be called from any account because the country code is included.
- Scenario 2: The UK number is in the contact list as 20 7551 8700.
- Result: This number can only be dialed from an account whose number begins with +44 (i.e. a UK account).
Contact List Formats, Fields, and Tables
Contact lists are used to store and organize contact information. Once you import a contact list into CX Contact, you can use it for one or multiple campaign groups.
On the Lists page, you will learn how to work with contact lists, but first it's important to understand the basics:
Supported File Formats
CX Contact supports the following file formats for contact lists and suppression lists:
The easiest text file format for importing contact information is comma separated value (CSV). In a CSV file, each record is on its own row, and each field within a record is delimited, or separated, with commas.
Important: We recommend you use a header record, the first row of the list, which names and describes the data fields. The header row is used to govern the mapping between the fields in the data file and the fields in the contact list.
You can import a contact list in a text file format, including any of the following:
|XLS||Microsoft Excel files are supported.|
|XLSX||Microsoft Excel Open XML Format Spreadsheet files are supported.|
Contact List Fields
A contact list can contain any or all of the fields described in this section. While the Device field (at least one) is the only mandatory field, Genesys recommends you also include a Client ID field. Otherwise, that field will be auto-filled with the Device information (phone number, for example).
Contact List Import
When you import a list into CX Contact, it can contain any or all of the fields listed in the table below.
|Type of Information||Description|
ImportantIf the data in any of your Other or General fields contains commas, those fields must be enclosed in double quotation marks.
|Other (User-defined Fields)||Other1 to OtherN are user-defined fields, meaning you use them to specify free-form information about the contact. The character limit for these fields is 1,024.
By default, these fields are labelled as Other1, Other2, Other3, and so on, but you can override the default labels to clearly identify what the field is used for. Refer to the Create or Manage Field Labels page for more information.
|Device||Device1 - Device10 fields are used to store the contact's phone number. Phone numbers can be entered using the following format:
However, it's safe to use the country code in all circumstances. Click to see examples.
ImportantWhen a file is imported, all phone numbers, regardless of format, are normalized to E.164 standards (i.e. + followed by country code).
Contact List Export
When you export a contact list from CX Contact, the list can contain any of the fields listed in the table above, in addition to the fields listed in the table below.
|Number of Attempts||Integer|
|ISO country Code (Contact)||String|
|Time Zone DBID (Contact)||Integer|
|Time Zone Name (Contact)||String|
|Call Time||Integer, UNIX Epoch|
|Country Code (Device)||String|
|ISO Country Code (Device)||String|
|Device Mask||Decimal integer|
|State/Region Code (Device)||String|
|Timezone DBID (Device)||Integer|
|Time Zone Name (Device)||String|
|Number in Chain||Integer|
|Contact Info (Device)||String|
|Contact Info Type||Enum|
|Scheduled Time||Integer, UNIX Epoch|
|Time Zone DBID||Integer|
Contact List Database Tables
When contact list data is imported into CX Contact, the data is stored in a database table. In CX Contact, there are two distinct database tables: the main table and the secondary table. There are distinct differences between the two:
ImportantUse these fields for any data that will be part of a dialing filter or contact order, or for data that will be edited by an agent.
It's possible that the contact data you import into CX Contact is stored into two separate database tables.
User-defined fields used:
In this scenario, two tables are used in the database: the main table and the secondary table.
The main table contains two records for John Smith - one for each device. It includes all customer data, including the data contained in the Other5 and Other20 fields.
The secondary table contains the user data contained in Other21 and Other22 fields:
In this table, you will still see two separate records for John Smith, but this time the records are not tied to a device; instead, they are tied to a Chain ID. In this example, the value of ud_chain_id is 1, which, as you can see in the main contact list table, is associated with customer John Smith. Also note that the labels in the header row always contain the prefix ud. The remaining part of the labels match to those in the main table.
You'll also notice that the Other21 and Other22 fields (the amount John Smith promised to pay and the date on which he promised to pay it) are not standard column headings in this table; instead, they're presented as user data within a record. This table is designed that way to support filtering functionality within CX Contact, meaning that CX Contact can easily join the two tables together when it receives a request to filter data (in the case of selection rules) within the contact list.
Refer to the Import a Specification File page to see how a database table is created from a specification file.