View table: PDMTable

The following tables and columns potentially contain PII:

For audit purposes, a value of "NULL" in a record indicates that the field was evaluated for a particular instance of PII and was found to be empty.

By default, data is retained in the CTL_GDPR_HISTORY table for 15 days. You can configure the days-to-keep-gdpr-history option to specify a different retention period, up to 30 days.

For more information about Genesys Info Mart support for GDPR compliance, see General Data Protection Regulation (GDPR) and Genesys Info Mart Support for GDPR in the Genesys Security Deployment Guide.

This dimension table records geographical locations of agents for both voice and multimedia login sessions. Each row describes one location as reported for a given agent login session. Because a voice login session and a multimedia login session for the same agent are reported separately from different data sources, the location values might differ for voice and multimedia media types.

This dimension table records geographical locations of agents for both voice and multimedia login sessions. Each row describes one location as reported for a given agent login session. Because a voice login session and a multimedia login session for the same agent are reported separately from different data sources, the location values might differ for voice and multimedia media types.

Writer's note: Reviewers, should the next paragraph be deleted altogether, or just delete "thread" from the phrases, "interaction thread" and "thread metrics"?
This dimension enables IRFs to be described based on a number of aspects of participation in an interaction thread at the same time, and it enables downstream reporting applications to report thread metrics for agent and other handling resources at the agent level and at the tenant level.

This table indicates a cause for contact attempt termination. Outbound Contact Server (OCS) provides this data as a cause of the final transition to Unloaded state for a contact attempt record. This data may be useful in a report to classify the causes for the termination of the outbound processing. For example, the ChainRejected and ChainReschedToContinue dispositions distinguish between rejected and rescheduled records, respectively. In addition, the final transition has a descriptor that provides further details of the transition — for example, whether rescheduling was caused by an agent or by the system. This release supports the descriptor for the CHAINEVENTRECORDRESCHEDULE disposition only.

Is the note still true?

Each fact is based on application data attributes in a reporting event produced by BGS. BGS generates the event when the bot session ends and publishes the event as a Kafka message. Genesys Info Mart pulls the data directly from Kafka and transforms it to combine the statistics in each event into a single BGS_SESSION_FACT record. Rows are inserted once and are not updated.

The MEDIA_SERVER_IXN_GUID links the BGS_SESSION_FACT record with the CHAT_SESSION_FACT record, as well as with the related INTERACTION_FACT (IF).

Writer's note: The description probably needs to be extended, depending on the meaning of OUTCOME. Would the following addition be correct: "There are separate rows for successful and failed invocations of each bot."

Each fact is based on user data sent in an Interaction Server reporting event when the chat session ends. Genesys Info Mart extracts the KVP data from the G_USERDATA_HISTORY table in IDB reporting event, and the transformation job combines the statistics in each event into a single CHAT_SESSION_FACT record. Writer's note: Pls. esp. confirm the next statement. Rows are inserted on receipt of the reporting event and are not updated. The chat statistics reported in each record are summarized by session and are not connected to specific agents or, in deployments that include Bot Gateway Server (BGS), bots.

The MEDIA_SERVER_IXN_GUID links the CHAT_SESSION_FACT record with the related INTERACTION_FACT (IF). In deployments that include BGS, the MEDIA_SERVER_IXN_GUID also links the CHAT_SESSION_FACT record with the related BGS_SESSION_FACT records. In this way, Genesys Info Mart enables you to generate reports that provide details about Genesys Chat or Advanced Chat activity at the interaction level, session level, and chat bot level:

• The MEDIA_SERVER_IXN_GUID links the CHAT_SESSION_FACT record with the related INTERACTION_FACT (IF).
• In deployments that include BGS, the MEDIA_SERVER_IXN_GUID also links the CHAT_SESSION_FACT record with the related BGS_SESSION_FACT records.
• In Genesys Multicloud CX deployments with Advanced Chat, the THREAD_ID links the CHAT_SESSION_FACT record with the related CHAT_THREAD_FACT. To get interaction details associated with a thread, you can join CHAT_SESSION_FACT and IF (via the MEDIA_SERVER_IXN_GUID) and then filter the results by CHAT_SESSION_FACT.THREAD_ID.

Terminology note

The meanings of terms such as interaction, session, thread, and conversation have evolved with Genesys chat implementations, and these terms might have different technical meanings in different contexts, depending on the type and version of chat implementation in your deployment.

• For the CHAT_SESSION_FACT table, the reporting entity is a set of chat messages with a particular customer on a single topic. The messages occur in close time proximity to each other. From the point of view of the server managing the chat activity, the messages occur within a single interaction.

  In the Genesys Info Mart documentation, the reporting entity that is the subject of CHAT_SESSION_FACT records is always referred to as a session. In certain chat implementations in cloud deployments and, therefore, in documentation describing those deployments, such a set of messages could be referred to as an interaction, and the term session could have a different meaning (see next bullet).

• For the CHAT_THREAD_FACT table, the reporting entity is a thread of multiple chat interactions with a particular customer over time.

  In the Genesys Info Mart documentation, the reporting entity that is the subject of CHAT_THREAD_FACT records is always referred to as a thread. In certain chat implementations in cloud deployments and, therefore, in documentation describing those deployments, these linked interactions, or threads, are referred to as sessions or conversations. As noted in the previous bullet, in the Genesys Info Mart documentation the term session always refers to the individual interactions in a thread.

• The term asynchronous chat or asynchronous interactions refers to chat interactions when both parties are not present in the chat at the same time. The types of supported asynchronous chat scenarios depend on the type and version of chat implementation in your deployment and determine what columns are populated in the CHAT_SESSION_FACT table.

Each fact is based on user data about the chat thread sent in an Interaction Server reporting event when a particular chat session ends. Genesys Info Mart extracts the KVP data from the G_USERDATA_HISTORY table in IDB reporting event, and the transformation job combines the statistics in each event into a single CHAT_THREAD_FACT record. Rows are inserted on receipt of the reporting event; rows are updated when a subsequent reporting event is received about a new chat session that is part of the same thread. The chat statistics reported in each record are summarized by thread and are not connected to specific agents.

The THREAD_ID links the CHAT_THREAD_FACT record with the related CHAT_SESSION_FACT.

Terminology note

The meanings of terms such as interaction, session, thread, and conversation have evolved with Genesys chat implementations, and these terms might have different technical meanings in different contexts, depending on the type and version of chat implementation in your deployment.

• For the CHAT_SESSION_FACT table, the reporting entity is a set of chat messages with a particular customer on a single topic. The messages occur in close time proximity to each other. From the point of view of the server managing the chat activity, the messages occur within a single interaction.

  In the Genesys Info Mart documentation, the reporting entity that is the subject of CHAT_SESSION_FACT records is always referred to as a session. In certain chat implementations in cloud deployments and, therefore, in documentation describing those deployments, such a set of messages could be referred to as an interaction, and the term session could have a different meaning (see next bullet).

• For the CHAT_THREAD_FACT table, the reporting entity is a thread of multiple chat interactions with a particular customer over time.

  In the Genesys Info Mart documentation, the reporting entity that is the subject of CHAT_THREAD_FACT records is always referred to as a thread. In certain chat implementations in cloud deployments and, therefore, in documentation describing those deployments, these linked interactions, or threads, are referred to as sessions or conversations. As noted in the previous bullet, in the Genesys Info Mart documentation the term session always refers to the individual interactions in a thread.

The MEDIA_SERVER_IXN_GUID links the COBROWSE_FACT record with the INTERACTION_FACT (IF) record for the Voice or Chat interaction that is associated with the Co-browse session. In this way, Genesys Info Mart enables you to generate reports that provide details about Genesys Co-browse activity in conjunction with the underlying interaction activity.

Writer's note: What needs to change in the following paragraph for (a) AWS, (b) Azure, or (c) PE?
Starting with release 8.5.015.07, you can control whether Genesys Info Mart creates separate CONTACT_ATTEMPT_FACT (CAF) records or a single, aggregated CAF record for calls dialed in the context of the same CALL_ATTEMPT_GUID. The default is a single, aggregated record. Prior to release 8.5.015.07, Genesys Info Mart always created separate records for each call attempt dialed in the context of the same CALL_ATTEMPT_GUID. If you want to retain the prior behavior, set the ocs-caf-aggregates-calls option to false.

The grain of the fact is an accumulating snapshot that represents the duration of the attempt. Record-based columns are populated with data from the first record associated with the contact attempt. Rows are inserted only when the attempt is completed, and they are not updated.

The CALL_ATTEMPT_ID enables you to link a CAF record with the associated Interaction Resource Fact (IRF).

The following tables and columns potentially contain PII:

For audit purposes, a value of "NULL" in a record indicates that the field was evaluated for a particular instance of PII and was found to be empty.

By default, data is retained in the CTL_GDPR_HISTORY table for 15 days. You can configure the days-to-keep-gdpr-history option to specify a different retention period, up to 30 days.

For more information about Genesys Info Mart support for GDPR compliance, see General Data Protection Regulation (GDPR) and Genesys Info Mart Support for GDPR in the Genesys Security Deployment Guide.

Custom DATE_TIME tables can be added to the schema at any point during or after the Genesys Info Mart deployment. These tables have the same structure as the DATE_TIME table, are controlled with dedicated configuration options, and are populated by using algorithms that are similar to those for the DATE_TIME table.

By default, the DATE_TIME calendar is a Gregorian, not a fiscal, calendar. Values that describe the weeks in which dates belong are fixed to begin on Sunday, with the exception of the first week of the year, which may contain fewer than seven days and may start on a day other than Sunday. The last week of a year may also contain fewer than seven days. This setting is referred to as "simple week numbering" because the calendar year and the week-numbering year coincide. By customizing settings in the date-time configuration section before Genesys Info Mart is initialized, you can change the week starting day, the minimum number of days in the first week of the year, and the time zone. Alternatively, by changing the fiscal-year-week-pattern setting, you can configure the calendar to be a fiscal one.

If you want to change any of the fundamental features of the DATE_TIME dimension during runtime, you must take special steps to avoid introducing inconsistencies into your calendar data and compromising your reporting results. For information about changing calendar settings during runtime, see the procedure about changing calendar options in the Genesys Info Mart Operations Guide.

Day and month designations (such as "Sunday" and "January") are localizable; other abbreviations, such as "Q" for quarter, are not.

The DATE_TIME_NEXT_* keys facilitate the retrieval of data for a defined reporting interval by identifying all of the rows in the table that define the upper boundary of the reporting interval.

The LABEL_* fields provide various string representations of a standard calendar date and/or 15-minute interval.

The RUNNING_* fields facilitate the search of facts for the last x number of years, quarters, months, weeks, days, hours, or subhours.

The CALLING_LIST view is based on this table.

Writer's note: Most column descriptions are from the ICON PDM. Reviewers, please especially confirm GSYS_* column descriptions. The other GIDB tables will be made consistent with whatever changes are made here.

Writer's note: Again, is this table now always populated?

The PLACE view is based on this table.

Writer's note: Same as previous
Note: In a SIP Cluster environment, this table might not be populated because the objects about which this table typically stores information are not required. However, if the objects usually recorded in this table are created in the Configuration Layer, data about them appears in the table in the same way as in a non-Cluster environment.

Writer's note: Reviewers, does the following note still apply, or is this table now always populated?
Note: In a SIP Cluster environment, this table might not be populated because the objects about which this table typically stores information are not required. However, if the objects usually recorded in this table are created in the Configuration Layer, data about them appears in the table in the same way as in a non-Cluster environment.

The MEDIA_SERVER_IXN_GUID links the GPM_FACT record with the related INTERACTION_FACT (IF), and the RESOURCE_KEY enables you to then link further to an INTERACTION_RESOURCE_FACT (IRF). Starting with release 8.5.014.19, you can also use the MEDIA_SERVER_IXN_GUID and the VQ_GUID to link GPM_FACT records with related MEDIATION_SEGMENT_FACT (MSF) records. In this way, the GPM_FACT table enables you to generate reports that provide interaction-level and queue-level detail about Predictive Routing usage and its impact on KPIs, as well as evaluate the results for various models and predictors.

• Agent Group
• DN Group

The data is based on the records that are stored in the GC_ANNEX table of the configuration IDB for these configuration objects. Genesys Interactive Insights uses the data to control visibility for certain data and reports.

A new row is issued for each geographical location, business line, or organizational structure attribute that is specified for a resource group as a configuration option on the Annex tab of the corresponding configuration object. Changing the name of the specified option causes a new row to be created. Changing the name of the specified section causes a new row to be created for each option that is associated with this section. Deleting the section causes all records for associated options to be terminated.

Each row in this table describes a distinct combination of business attributes that characterize the interaction. A new row is issued for each distinct combination of business attributes. The values are populated from the user data (attached data or UserEvent-based KVP data) according to a propagation rule, configurable for each column.

For multimedia interactions, the grain of the fact is the same as for voice interactions in the majority of cases. A new INTERACTION_FACT row is generated for:

• Each new root interaction (identified by a unique ROOTIRID)
• Each new inbound interaction, even if this interaction is associated with an existing root interaction (has the same ROOTIRID value) as could be the case with an inbound customer reply interaction
• A late outbound reply (a multimedia interaction representing an e-mail reply that is created after the parent interaction has already been terminated)

• Start a new interaction.
• Handle an existing interaction.
• Mediate and handle an interaction.

IRF resources include handling resources (such as agents, self-service IVRs, and DNs that have no associated agents) and mediation resources in which the IRF ends in mediation (such as queues, routing points, and non-self service IVRs).

A row is added to this table as a result of one of the following call scenarios:

• A new interaction was initiated by a contact center resource.
• An attempt to transfer an interaction or an attempt to consult or conference additional contact center resources was initiated by a handling resource.
• An interaction was delivered to a handling resource, either directly or through one or more mediation resources.
• An interaction was delivered to a handling resource as a result of consultation, transfer, or conference, either directly or through one or more mediation resources.
• An interaction was abandoned at a mediation resource while trying to reach a handling resource.
• An attempt to deliver a transfer or consultation or an attempt to initiate a conference was abandoned while the transferred, consultation, or conferenced interaction was at a mediation resource, trying to reach a handling resource.
• Starting with release 8.5.003, in eServices outbound scenarios where an outbound interaction is created outside the scope of eServices (for example, by OCS) and placed into an Interaction Queue, a strategy handles the interaction without agent involvement.

This table facilitates the creation of reports and serves as one of the primary tables from which aggregation tables are populated.

The grain of the fact is an accumulating snapshot of a contact center resource's contiguous participation in the interaction, including the time that is spent wrapping up the interaction.

IRF start and end dates and times are stored as facts in the UTC time zone. They are also stored as DATE_TIME dimension references.

Media-neutral counts and durations are provided to categorize the time that is spent on various activities, such as time that is spent in mediation in queues, routing points, and IVRs.

Customer-related counts and durations are provided to categorize the time that is spent on the interactions in which customers are present, regardless of whether the customer is internal or external.

The RESOURCE_ dimension represents the resource that is involved with this interaction resource fact.

The PLACE dimension indicates the place at which the IRF was processed.

The TECHNICAL_DESCRIPTOR dimension identifies the role of the resource and the technical result of its involvement with respect to the IRF.

The INTERACTION_DESCRIPTOR dimension identifies the customer segment (indicating the value of the customer) and the type of service that is being requested.

The STRATEGY dimension identifies the Genesys routing strategy that processed the IRF.

The ROUTING_TARGET and REQUESTED_SKILL dimensions indicate the activities of the Genesys router by identifying the target that was selected and the list of skills that were requested to process the IRF.

The ANCHOR_FLAGS dimension identifies aspects of a handling resource’s participation in interactions that are relevant for metrics about unique participations in an interaction or thread.

As previously indicated, many interaction attributes are formally modeled. However, deployment-specific attributes are represented in the model in the form of user-defined attached data. Low-cardinality string user data that is associated with the interaction resource are represented by using the IRF_USER_DATA_KEYS and USER_DATA_CUST_DIM_1 dimensions. Numeric user data and high-cardinality string user data that are associated with the interaction resource are represented by using the IRF_USER_DATA_GEN_1 and IRF_USER_DATA_CUST_1 fact extension tables.

This table allows facts to be described by the interaction-related state of the associated IRF resource. Each row describes one distinct interaction-related state, combined with a state descriptor and state role.

Note: States are not generated for routing point or ACD queue IRF resources, as these resources have only one state.

The name of this table and the column names are configurable and may differ in your deployment.

The table stores high-cardinality data for up to 16 key-value pairs (KVPs) that are associated with interactions. Each row describes a combination of user-defined custom attributes that characterize the interaction. A new row is issued for each new interaction resource fact. If the DN- or Script-level [gim-etl].link-msf-userdata configuration option or, starting with release 8.5.003, the application-level link-msf-userdata-voice or link-msf-userdata-mm configuration options are specified, a new row is also issued for each new mediation segment fact, to store the user data for an interaction that is in mediation. The row is populated according to a propagation rule, configurable for each KVP.

The table stores high-cardinality data for a set of predefined KVPs that are associated with interactions. (The Revenue and Satisfaction KVPs are also included in this table although the associated attributes are not currently predefined in Genesys Configuration Database.) Each row describes a combination of user-defined custom attributes that characterize the interaction. A new row is issued for each new interaction resource fact. If the DN-level [gim-etl].link-msf-userdata configuration option or, starting with release 8.5.003 the application-level link-msf-userdata-voice or link-msf-userdata-mm configuration options are specified, a new row is also issued for each new mediation segment fact, to store the user data for an interaction that is in mediation. The values are populated from user data (attached data or UserEvent-based KVP data) according to a propagation rule, configurable for each column.

The table includes a foreign key that references either an IRF record or an MSF record. The table also includes references to foreign key columns for the predefined dimensions that are based on user data and to a configurable number of Custom_Key columns.

Each row describes a combination of foreign keys to predefined and custom dimensions that characterize the interaction. A new row is issued for each new interaction resource fact. If the DN- or Script-level [gim-etl].link-msf-userdata configuration option or, starting with release 8.5.003, the application-level link-msf-userdata-voice or link-msf-userdata-mm configuration options are specified, a new row is also issued for each new mediation segment fact, to store the user data for an interaction that is in mediation.

If an agent handles multiple interactions simultaneously, this table may include facts that happen simultaneously on different interactions, but that are associated with the same agent.

Each row in this table describes a contact list record that was not attempted because CX Contact suppressed the record during preloading

The LDR_LIST_KEY enables you to link an LDR_FACT record with the LDR_LIST table; LDR_LIST.LIST_ID contains the DBID of the contact list object and can be joined further to CALLING_LIST_METRIC_FACT and other Info Mart tables.

New 3rd Party Media media types can be populated in this dimension manually. Genesys recommends that you manually insert online media types into this table prior to their use, so that they are processed and represented properly starting with their first appearance in data. The Genesys Info Mart Server also adds new 3rd Party Media media types to this table as they are encountered, storing them as offline media by default. For media types that are truly online media, the IS_ONLINE value should be changed manually in this case. Refer to {{{MC}}} on the {{{MC}}} page in the Genesys Info Mart Deployment Guide for instructions.

• Abandoned in the mediation DN
• Cleared from the mediation DN (for virtual queues only)
• Distributed from the mediation DN, including the time that it takes the interaction to be answered by the target resource or to be abandoned while alerting at the target resource

For voice, only completed ACD queue and virtual queue activity is populated; for multimedia, both active and completed virtual queue activity is populated.

In releases prior to 8.5.003, the populate-mm-ixnqueue-facts configuration option disables the population of eServices/Multimedia Interaction Queue activity to the MSF table. Starting with release 8.5.003, an MSF record is populated for the starting Interaction Queue of an Inbound Interaction, even if populate-mm-ixnqueue-facts is set to false.

The mediation segment start and end dates and times are stored as facts in the UTC format.

The POST_CALL_SURVEY_DIM_* tables are not part of the default Genesys Info Mart database schema. In deployments that rely on Genesys Info Mart for reporting on Post-Call Survey user data that may come attached with interactions, use the applicable Genesys-provided make_gim_post_call_survey*.sql script to add these tables to the schema.

The POST_CALL_SURVEY_DIM_* tables are not part of the default Genesys Info Mart database schema. In deployments that rely on Genesys Info Mart for reporting on Post-Call Survey user data that may come attached with interactions, use the applicable Genesys-provided make_gim_post_call_survey*.sql script to add these tables to the schema.

The POST_CALL_SURVEY_DIM_* tables are not part of the default Genesys Info Mart database schema. In deployments that rely on Genesys Info Mart for reporting on Post-Call Survey user data that may come attached with interactions, use the applicable Genesys-provided make_gim_post_call_survey*.sql script to add these tables to the schema.

The POST_CALL_SURVEY_DIM_* tables are not part of the default Genesys Info Mart database schema. In deployments that rely on Genesys Info Mart for reporting on Post-Call Survey user data that may come attached with interactions, use the applicable Genesys-provided make_gim_post_call_survey*.sql script to add these tables to the schema.

The POST_CALL_SURVEY_DIM_* tables are not part of the default Genesys Info Mart database schema. In deployments that rely on Genesys Info Mart for reporting on Post-Call Survey user data that may come attached with interactions, use the applicable Genesys-provided make_gim_post_call_survey*.sql script to add these tables to the schema.

The POST_CALL_SURVEY_DIM_* tables are not part of the default Genesys Info Mart database schema. In deployments that rely on Genesys Info Mart for reporting on Post-Call Survey user data that may come attached with interactions, use the applicable Genesys-provided make_gim_post_call_survey*.sql script to add these tables to the schema.

Deleting a script, routing point, queue, or another DN and re-creating it under the same name causes a new row to be issued. Changing agent attributes--such as last name, first name, and employee ID--causes an update to an existing row. Deleting an agent and re-creating it with the same attributes causes a new row to be issued.

Note: The Genesys Info Mart ETL does not populate the EXTERNAL_RESOURCE_ID and IVR_NAME columns.

The data is based on the records for these configuration objects that are stored in the GC_ANNEX table of the configuration IDB. Genesys Interactive Insights uses the data associated with Person configuration objects to control visibility for certain data and reports.

A new row is issued for each configuration option specified in an RPT* section (in other words, in a configuration section with section name starting with “RPT”) on the Annex tab of the corresponding configuration object. Changing the value of the specified option causes an update to an existing row. Changing the name of the specified option causes a new row to be created. Changing the name of the specified section causes a new row to be created for each option that is associated with this section. Deleting the section causes all records for associated options to be terminated.

Each row describes a routing target that has been used by the router. Refer to the ROUTING_TARGET_TYPE column for a list of target types. A new row is issued for each distinct routing target that is encountered as attached data in the interaction source data.