When designing the Workflow to be used with Genesys Cloud interactions, there are a few core points to consider: wrap-up codes, closure behaviour, attaching notes to the interaction, and the available data within the Workflow. There are also more situational considerations, such as interacting with Genesys Cloud via JavaScript, and how to handle web chat interactions.

 

Data 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:

 

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 and Scripting systems more easily.

 

 

When the Workflow is closed, any outcome and notes that have been set during the Workflow run 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 [var_csOBOutcomeCode] and [var_csOBComments], or by setting the values of the awakenOutcomeCode and awakenOutcomeComments keys in the Script.Data layer, or by using an Outcome - Button or Outcome - List control to set just the outcome. 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.

 

 

If an interaction is ended - either by the caller/recipient (in the case of a voice interaction), or by the agent 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 first Workflow run will be abandoned in an indeterminate state within Scripting.

 

 

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 scripts together (e.g. a "master" script that is popped that then queues one or more subsequent scripts 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 [var_disconnectOnClose], use the disconnectOnClose JavaScript function, or assign a value to the awakenDisconnectOnClose key in the Script.Data layer. Whichever method is used last will determine the set wrap-up codes and notes, and valid values are true / false, "true" / "false", or "1" / "0".