Popping Mechanisms

 

Scripting offers many different mechanisms for initiating a Workflow pop. The most common methods are using a dialler, manually opening it, a JavaScript function, or via URL. Note that some integrations may use a combination of these; for example, a dialler solution (such as the PureEngage Integration) may use a URL to actually pop the Workflow.

 

Campaigns are created in the dialler, and linked to a Workflow via External Links.

 

Different diallers have the ability to pop Scripting in different ways, typically either utilising JavaScript or URL popping to execute the pop; information on each integration's pop method and further details can be found in the Telephony Integration Matrix. It should be noted that diallers are unable to make use of Campaign Aliases, as described further in Campaign Popping.

 

When a user launches a campaign on the Agent Desktop, they are invoking a Workflow pop for either the selected record or for a new record. The campaign they select defines which Workflow is loaded.

 

The Workflow pop is invoked by a JavaScript command to the Scripting Desktop. See JavaScript Popping for further information.

 

Usually used when the Desktop in Scripting is not required, and the Workflow needs to be embedded into an alternative integration. See URL Popping for further information.

 

A cloud-based RESTful webservice can be called to invoke a Workflow pop to a specific agent on a specific Scripting system. See Integration - Cloud API for further information.

 

 

To enable the Workflow to be linked to an external campaign, a plugin is required to link Scripting and the integration.

 

There are two standard types of plugins: One-Way, and Two-Way. The plugins pop a Workflow in Scripting, and can supply the Workflow with data from with a campaign record, or save collected data back to a campaign record at Workflow completion.

 

1) One-Way: allows the Workflow builder to type free text to create a campaign manually in the External Links section, which is then used in a URL or JavaScript function to pop the Workflow. Whilst the Linked Column attribute will appear in Workflow controls, the data flow is one-way only; although data can be passed in as part of the pop parameters, there is no destination for it to return to. Data captured during the Workflow can still be written out to SQL tables or a web endpoint as usual, so SSRS reports or other methods can still be used to extract and use the data.

 

2) Two-Way: linked to an external integration or dialler (such as PureConnect, PureEngage, etc.), a list of dialler-available campaigns are presented to the Workflow. Data linking is available to Workflow controls via the Linked Column attribute that appears once the campaign is linked to the Workflow. The data link is two-way, so information can be obtained from the external solution/dialler, altered within the Workflow, and then returned to the external solution/dialler at Workflow completion.

 

 

All Workflows need an identifier in the form of a Campaign Name or Campaign Alias. The identifier is either generated automatically by the dialler/External Links, or created manually in the Campaigns section. Note that the identifier must be unique, and that more than one identifier can be linked to a Workflow, but only one Workflow can be linked to each identifier. The process of matching the identifier to the specific Workflow is documented in Campaign Popping. Finally, the Workflow linked to the identifier must have a published version to be popped.

 

If the popping user doesn't have permissions to the linked Campaign, then the pop won't be completed. If the attempted pop was via URL, then a screen will be displayed stating that the user lacks permissions for the Campaign. If the attempted pop was via JavaScript, then the user won't leave their current page and, if enabled, a warning Toast will be displayed.

 

The reference is used to link the data pulled into and/or written out from a Workflow run from an external source, if configured, such as a Dialler or other External Link. When popping a Workflow, the reference can either be specified to a desired value, or left blank to have a generic reference automatically generated.

 

The value of the current reference within a Workflow run is held within [var_csReference], and this can then be used as the specified reference for a popped Workflow if desired. This allows follow-on Workflows to continue pulling in relevant record data, and writing captured and calculated data back to the record source.

 

Every Workflow run will exist within an activity, and when popping a Workflow it is possible to choose to create it within the current activity (if available), or to create a new activity. Activities determine the order in which queued Workflows will actually be popped, and also control access to any shared data.

 

All Workflows within an activity will share access to a common Script.Data pool to allow data to be shared between the Workflows in that activity. This means that if two Workflows are queued with the first retaining the current activity and the second creating a new activity, then the original Workflow and first queued Workflow will have access to the same data within Script.Data, whereas the second queued Workflow in the new activity will only have access to any data specified in the pop invocation.

 

Multiple Workflow pops can be queued within a single Workflow, both for the current activity as well as for new activities, and the order in which they are queued will influence the order in which they are popped when each Workflow is exited. Specifically, all of the Workflows queued within the current activity will be popped in the order that they were queued, and then the first new activity to be queued will have its queued Workflows popped in sequence, and then the second new activity to be queued will be popped, and so on.

 

Within a Workflow (inside Activity A, with Reference 1) we could queue up three Workflow pops: the first in a new activity (Activity B) with a new reference (Reference 2), the second in the original activity (Activity A) but another new reference (Reference 3), and the final within the original activity and reference (Activity A, with Reference 1).

 

 

In this situation, when the original Workflow is exited, the first Workflow to be popped is actually the second that was queued; it is the earliest queued Workflow within the current activity, and so is reached first. However, this Workflow has a different reference to the original Workflow, so despite sharing an Activity it won't have its data written back to the same record as the original Workflow. As it shares an activity with the original Workflow, it can still access the same contents within the Script.Data layer, and any data written back into Script.Data will still be available in following Workflows within the same activity.

 

Once that Workflow run has been exited, the next Workflow to be popped is actually the third to have been queued; it is the earliest remaining queued Workflow within the current activity. This Workflow shares the original Workflow's reference, and so it will have its data written back to the same record as the original Workflow when it is completed.

 

Finally, the last Workflow to be popped is actually the first that was queued; as it was queued for a new activity, it only gets popped after the current activity has completed all of its queued Workflows. It has a different reference and is also within a different activity, so the Workflow won't write data back to the original record upon completion, and it won't have access to the same Script.Data layer that all of the previous Workflows in this example did.

 

 

Data can be posted into the activity, becoming available for any Fields configured with Linked Columns. The Linked Columns each match to any posted data keys in a case-insensitive manner, so all instances of that keyname in the Linked Columns will take the value of the first case-insensitive matching key from the posted data. To access data for specific keys that are identical apart from their casing, all keys are available as case-sensitive keys in the Script.Data layer.