Workflow Design for Genesys Cloud
When a record is popped by Genesys Cloud, the value of [var_csReference] will normally be the popped conversation's ID from Genesys Cloud. However, when launching a record from an outbound campaign then the value of [var_csReference] is instead taken from the ID of the current contact in the contact list.
Data from Genesys Cloud passed with the pop can be accessed either via
Link Columns (if using External Links), or via the
Script.Data JavaScript layer (in either scenario). While there are
examples of common data structures, the structure and content of the passed pop data can vary between interaction types, state, and customisation. It is recommended to launch a test pop to determine the content and keys that can be linked or utilised. Below is an example of how to see the passed data structure:
|
console.log(Script.Data.GetPostData());
|
It is strongly recommended that at a minimum the conversationId element of the pop data always be mapped to a Field within the Workflow, as this equates to the Interaction ID within Genesys Cloud. If this value is stored within the Workflow, it then allows the cross-comparison of interactions and data between the Genesys Cloud and Intelligent Agent systems more easily.
Wrap-up & Comments
When the Workflow is closed, any outcome and notes that have been set during the record will be returned to Genesys Cloud and set against the interaction as the wrap-up code and notes respectively. The outcome and notes can either be set directly by assigning values to the
[var_csOBOutcomeCode] and
[var_csOBComments] System Variables, by setting the values of the
awakenOutcomeCode and
awakenOutcomeComments keys in the
Script.Data layer, or by using an
Outcome - Button or
Outcome - List Field (although this can only set the outcome and not the notes). If multiple methods are used, then whichever method is used last will determine the set wrap-up codes and notes.
If an outcome isn't provided or doesn't (case sensitive) match a valid wrap-up code for the interaction, then a Toast will be displayed to the agent upon closing the script.
External Interaction Completion
If a Genesys Cloud interaction is ended - either by the caller/recipient (in the case of a voice interaction), or by the user via the Genesys Cloud frame or soft phone - then the Workflow will still be open. The agent needs to ensure that the Workflow is closed out before they become eligible for a new interaction, or else the current record will be abandoned in an indeterminate state within Intelligent Agent if a new interaction is accepted.
Interaction Disconnection
By default, when the Workflow is closed it will automatically disconnect the active interaction within Genesys Cloud. This is typically desired, but may prevent specific processes such as chaining multiple Workflows together (e.g., a "parent" Workflow that is popped that then queues one or more subsequent "child" Workflows depending on circumstance), or performing transfers. As such, this behaviour can be disabled so that Workflows can be freely closed without also closing the interaction.
To control this behaviour, either create and then assign a value to the
[var_disconnectOnClose] Workflow Variable, use the
Script.Plugins.genesyscloud.disconnectOnClose JavaScript Helper Function, or assign a value to the
awakenDisconnectOnClose key in the
Script.Data layer. If multiple methods are used, then whichever method is used last will determine the set wrap-up codes and notes
. Valid values are true /
false,
"true" /
"false", or
"1" /
"0".
Determining Interaction Type
If a Workflow is linked by multiple Campaigns to many different interaction streams, it is possible to determine the current interaction's type by using some conditional logic. Below is an example of how to separate the different interaction types:
|
var postData = Script.Data.GetPostData();
if (postData.dialingMode) {
}
else if (postData.customerCall) {
}
else if (postData.customerEmail) {
}
else if (postData.customerChat) {
}
|
When performing internal transfers, it is critical to remember that two agents must not be running the same record simultaneously. As a record is popped whenever an agent is attached to a Genesys Cloud interaction, this means that a consult (or "warm") transfer should never be placed from an agent who is running a record to another agent who is also going to process the interaction in Intelligent Agent.
As such, when performing internal transfers you must use a blind (or "cold") transfer, with the original agent's record also being closed simultaneously with the transfer being placed.
