Jump to: navigation, search

Deploying Do Not Call Functionality

This topic discusses the deployment of Do Not Call functionality.

Do Not Call Table Structure

The Do Not Call table has a fixed structure, as shown in the following table. The customer_id field, like the phone field, is part of that established structure. The Do Not Call table does not require Format and Field configurations. Genesys Administrator generates this table if the Table Access object is present, but the physical table does not yet exist.

Note: If you manually add entries to the Do Not Call table, you must restart Outbound Contact Server (OCS) so that OCS can read the new records into its memory.
Alternatively, OCS will pick up these updates upon next reread of the Do Not Call list, if OCS is configured for such rereads. For a description of this functionality, see Rereading of the Do-Not-Call List.
Do Not Call Table Structure

Field Name



phone varchar (64) yes
customer_id varchar (64) yes
dnc_message varchar (255) yes
tenant_dbid decimal (18, 0) yes
campaign_dbid decimal (18, 0) yes
list_dbid decimal (18, 0) yes
is_internal int yes
time_stamp int yes
int yes
Note: The phone field in 6.5 was changed to the contact_info field in the 7.0 Calling List table. The phone field is still in the Do Not Call List table.

User-Defined Field for Do Not Call

The restriction on dialing a particular customer is an alternative to the Do Not Call restriction applied to a particular telephone number. The ability to apply a a Do Not Call request to a specific customer is helpful when the same phone number appears on more than one customer's records. For example, in a family or roommate situation, one member of the household might want to be on the Do Not Call list while another person at the same residence and with the same telephone number might not make that request.

The value of the customer_id option in the OCS Application object is the name of the field that the user designates for the customer identifier. At start-up, OCS reads all the records from the table referenced in the gsw_donotcall_list Table Access and populates two separate tables in memory with unique values from the phone field and from the customer_id field. Do Not Call requests from the agent desktop can also populate these tables in memory during runtime.

Configuration Procedure

Perform this procedure in Genesys Administrator to create a user-defined field to identify customers for a Do Not Call List. This new field will serve as the customer_id for Do Not Call requests and will be included in the UserData attached to T-Server events. As the value of the customer_id option in the OCS Application object, this field will correspond to the customer_id field in the Do Not Call (gsw_donotcall_list) table.

Creating a User-Defined Field to Identify Customers for the Do Not Call List


  1. Configure a Table Access object for the gsw_donotcall_list:
    • In Genesys Administrator, go to <Tenant> > Provisioning > Outbound Contact > Do Not Call List.
    • In the Configuration > Database, specify the following:
      • DB Access Point = <user-specific name of the DB Access Point>
      • Database Table = <user-specific name of the database table>
    Genesys Administrator automatically populates other required properties from the corresponding DB Access Point.
  2. Create the database table for the Do Not Call list:
    • In Genesys Administrator, go to <Tenant> > Operations > Calling Lists.
    Genesys Administrator automatically creates the database table if it is not created when the Table Access object for the gsw_donotcall_list is configured.
  3. Create a new user-defined Field object:
    • In Genesys Administrator, go to <Tenant> > Provisioning tab > Outbound Contact > Fields.
    • On the Configuration tab, specify the following:
      • Name = <user-specific name>
      • Data Type = varchar
      • Length = 64
      • Field Type = User-Defined Field
      • Select the Nullable and State Enabled checkboxes.
    • On the Options tab, create a new option, as follows:
      • Section = default
      • Name = send_attribute
      • Value = GSW_CUSTOMER_ID
  4. Create a Format which includes all the mandatory fields from Default_Outbound_70 and also the new user-defined Field; and then create a Calling List based on that, as described in Field Object, Format Object, and Calling List Object.
  5. Designate the new user-defined Field as Customer ID in the OCS Application object:
    • In Genesys Administrator, go to <Tenant> > Provisioning > Environment > Applications > Outbound.
    • In the OCS application, in the Options > OCServer section, create and define the customer_id option, as follows:
      • Section = OCServer
      • Name = customer_id
      • Value = <name of the new user-defined Field>


Updating the DNC List

Through Genesys Administrator, you can update a current DNC list with data from an external source. Genesys Administrator first reads data from an ASCII file, which is in comma-delimited format. The user then maps this data to the appropriate columns in the DNC list (database table).

The process to update or import data from an external source is composed of three steps:

  1. Selecting the data file and type.
  2. Assigning names to data columns.
  3. Specifying data import options.

For detailed instructions, see Framework Genesys Administrator Help (Provisioning Your Environment > Outbound Contact Object Types > Do Not Call List > Importing a Do Not Call List File).

OCS-Desktop Protocol Changes for DNC

A Do Not Call (DNC) request from an agent (GSW_AGENT_REQ_TYPE = DoNotCall) includes an attribute to specify the customer_id: GSW_CUSTOMER_ID. At least one attribute (GSW_PHONE or GSW_CUSTOMER_ID) must be present in the UserData of the request if the GSW_RECORD_HANDLE is not specified.

Do Not Call Duration

The Do Not Call Duration functionality enables you to set an expiration date for a DNC request. On the date of expiration, OCS removes or ignores the DNC entry.


To configure DNC Duration, you must first manually add the expires_at field to the Do Not Call table.

Enter the Database Definition Language (DDL) statement that applies to your database type:

  • PostgreSQL
ALTER TABLE <dnc_table_name> ADD COLUMN expires_at integer NULL
  • MS SQL
ALTER TABLE <dnc_table_name> ADD expires_at int NULL
  • Oracle
 ALTER TABLE <dnc_table_name> ADD expires_at int NULL

This field will store the expiration time in POSIX format (seconds since midnight of 01/01/1970). A value of 0 or NULL means the DNC entry never expires.

Next, configure the following options:

  • dnc-use-duration - Used to enable DNC Duration. If the value is set to false, there is no change in the way OCS treats a DNC entry. If the value is set to true, OCS stores the expires_at value found in the Do Not Call table and later retrieves the value to determine if a given DNC entry (for new dials only) is active (not expired) or expired.
  • dnc-default-duration - Used when the GSW_DURATION attribute is not specified in a DNC request that has a value specified in the GSW_RECORD_HANDLE attribute.
  • dnc-purge - Used to remove expired DNC entries. The purge occurs after OCS reads the DNC table after restart or after OCS re-reads the DNC table in accordance with the dnc-reread option.

Finally, add the GSW_DURATION attribute to the Desktop communication protocol (for both transports, T-Events and HTTP). This attribute represents the DNC duration, in seconds. OCS adds this value to the current time to calculate the expiration date, which it then stores in the Do Not Call table.

Handling Requests

The following scenarios describe the process OCS uses to handle DNC duration requests.

Scenario 1:

  • GSW_DURATION is not specified.
  • GSW_RECORD_HANDLE is not specified.
  • Resolution: OCS applies a value of 0. It does not refer to the dnc-default-duration option, regardless of the settings.

Scenario 2:

  • GSW_DURATION is not specified.
  • GSW_RECORD_HANDLE is specified.
  • Resolution: OCS retrieves the DNC duration from the dnc-default-duration option.

Scenario 3:

  • GSW_DURATION is specified.
  • dnc-default-duration is specified.
  • Resolution: OCS uses the GSW_DURATION value.

Handling Multiple Requests

If OCS receives multiple DNC requests for the same customer, and all of those requests have different expiration dates, it applies the later expiration date.

For example, if one DNC request for a given customer specifies an expiration date of January 1, 2018 and another DNC request for that same customer specifies an expiration date of March 1, 2018, OCS recognizes March 1, 2018 as the expiration date.

This page was last edited on April 6, 2020, at 18:30.
Comments or questions about this documentation? Contact us for support!