Cargo query

Each row in this table records a bot session, which represents a single conversation between a customer and the bot service that was invoked by the Bot block in the Designer application, while the interaction was being processed by the application. A session starts when the Bot block receives voice or chat input from the customer and ends when Designer either moves to an intent block or to an Error Handler block. There might be multiple bot sessions within a single Session Detail Record (SDR) session.

Writer's note: Should we say anything about how this bot reporting does or does not relate to bot activity recorded in CHAT_SESSION_FACT (link)? To put it another way: Is there any possibility of confusion if a user follows the trail from SDR_BOTS_FACT through SDR_SESSION_FACT and INTERACTION_FACT to CHAT_SESSION_FACT?

Note that the word "attribute" is misspelled in the database table and column names.

Note that the word "attribute" is misspelled in the database table name.

A new row is inserted whenever there is the possibility that a new media-neutral summarized state was entered, such as when a summarized state begins in any media session for the resource, or when a summarized session for the resource ends. In these situations, the previous media-neutral state is ended, the winning state is re-evaluated, and the new highest-priority state (which may be the same as the previous one) is recorded. Therefore, there might be multiple sequential rows with the same state for the agent. A media-neutral state is also ended if it is still active at the end of an ETL cycle, and the winning state is re-evaluated at the beginning of the next ETL cycle. The rows are not updated.

The SM_MEDIA_NEUTRAL_STATE_FACT table does not record subsecond states, so there will never be more than one media-neutral state for an agent in the same second.

The SM_MEDIA_NEUTRAL_STATE_FACT table is populated up to the point where summarized state data is available for activity from both voice and multimedia data sources. Because evaluation of the highest media-neutral state can occur only after the media-specific summarized states have been transformed, population of the SM_MEDIA_NEUTRAL_STATE_FACT table is commonly one ETL cycle behind the SM_RES_STATE_FACT table.

If the extraction high-water marks (HWMs) of the voice and multimedia data domains differ, Genesys Info Mart will wait for summarized state data from the lagging data domain. The waiting period depends on the configured extract-data-stuck-threshold option value. Once the waiting period is over, Genesys Info Mart begins to populate the table based on available media-specific data.

The STUCK_FLAG indicates whether the highest-priority media-neutral state was determined based on data from only one of the data domains (voice or multimedia) — for example, because one of the data domains was lagging significantly behind the other, or because there is only one data domain in the deployment.

The start and end dates and times are stored as facts, in seconds that have elapsed since January 1, 1970. The start time is also stored as a DATE_TIME dimension reference.

A summary session represents the contiguous duration that an agent resource is logged in for a given media type, irrespective of the number of DNs, Places and/or queues to which the agent resource logs in. For voice, a summary session starts when an agent resource first logs in to any voice DN-queue combination. The session continues, irrespective of how many other voice DNs and/or queues the agent logs in to. The session ends when the agent resource logs out of all voice DNs and queues. For multimedia, a session is first created when the agent resource adds a media type to their login session. The login session continues until the agent resource removes the media type from their login session.

The start and end dates and times for both voice media and multimedia are stored as facts, in seconds that have elapsed since January 1, 1970. They are also stored as DATE_TIME dimension references.

Both active and completed sessions are populated.

A summary state represents the contiguous duration that an agent resource is logged in with a particular state for a given media type, irrespective of the number of DNs and/or queues to which the agent resource logs in. For voice, the summary state is chosen from among the concurrent states of all voice DNs to which the agent is logged in, based on the configured state priority list. For multimedia, there are no DNs, so that the summarized state represents the state of the agent, relative to the media type. Both active and completed resource states are written to this table.

Do Not Disturb is optionally factored into summary states, based on the configuration of the underlying Switch object.

The start and end dates and times for both voice and multimedia agent states are stored as facts, in seconds that have elapsed since January 1, 1970. They are also stored as DATE_TIME dimension references.

A summary state reason represents the contiguous duration for which an agent resource is logged in with a particular state reason, for a given media type, irrespective of the number of DNs and/or queues to which the agent resource logs in. Both active and completed state reasons are taken into consideration. Do Not Disturb is optionally factored into summary state reasons, based on the configuration of the underlying Switch object. Where multiple, concurrent reasons are associated with a resource state, the winning summary state reason is the reason that is associated with the state that has the highest priority.

The start and end dates and times for both voice media and multimedia are stored as facts, in seconds that have elapsed since January 1, 1970. They are also stored as DATE_TIME dimension references.

For detailed information about the available technical descriptor combinations, see Technical Descriptors in the Genesys Info Mart User's Guide. (Genesys Multicloud CX customers: For your convenience, the relevant page is reproduced here in the Reporting guide.)

This table is necessary to describe a contact's time zone in outbound campaigns, because time zones of campaign contacts may differ from the time zones of contact centers.

Note: Genesys recommends restricting the maximum length of the fields related to user data KVP in dimensional tables to comply with RDBMS limitations. Refer to RDBMS Considerations in the Genesys Info Mart Deployment Guide for more information.

A new row is created the first time that any interaction that is owned by a particular resource is placed into a particular Workbin object that has been defined in the Configuration Layer—in other words, the first time that a particular workbin instance is created.

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).

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.