Intelligent Agent offers many different mechanisms for initiating a Workflow pop. The most common methods are using an integration, manually opening it, a JavaScript Helper Function, via URL, or via the Awaken Intelligence Cloud API. Note that most integrations actually use a combination of the other options; for example, if the Intelligent Agent window is embedded within another system, that system may use a modified JavaScript pop.

 

Integrations vary, but in general they take the form of a controlling system (e.g., telephony) that distributes interactions among agents, and then either the controlling system directly invokes a pop in Intelligent Agent, or there is integration code within Intelligent Agent that listens to the interaction stream and pops a record as required.

 

Integrations will often utilise a Plugin within Intelligent Agent that is used to source the external interaction streams (e.g., campaigns, queues, or mailboxes) that can then be attached to Workflows via External Links. This may also allow data to be passed in to the record pop from the integration.

 

Agents can select from the Campaign List on the Desktop, opening the Campaign View for that Campaign. They will then be given the option of popping either an existing record, or a new record.

 

A pop can be invoked by a JavaScript command on the Intelligent Agent Desktop. This is commonly done when the Intelligent Agent system is embedded within a third-party system's iframe, allowing that system to trigger the Intelligent Agent pop.

 

See JavaScript Popping for further information.

 

A pop can be invoked by navigating to a specific URL that provides the requisite pop information. This is common done when the Intelligent Agent system is being operated by a third-party system but JavaScript popping isn't available for some reason; this may be because of a security restriction, or a limitation in the third-party system. This is the only kind of integration where the agent doesn't need to already be logged in and on the Desktop to receive the pop, but also adds some limitations to what can be done as part of the pop.

 

See URL Popping for further information.

 

A pop can be invoked by calling a cloud-based RESTful webservice to trigger a pop for a specific agent on a specific Intelligent Agent system.

 

See Integration - Cloud API for further information.

 

 

Commonly, to enable a Workflow to be linked to an external source of interactions, a Plugin is used to link Intelligent Agent and the integration.

 

There are two general types of Plugins: one-way, and two-way. The Plugins allow sourcing the Campaign name to be used in Intelligent Agent, and can supply the Workflow with data from the external record, or save collected data back to the external record at record completion.

 

1) One-way: for this type of integration, data can be passed into the record on pop from the external record, and is available either via the Script.Data layer, or via Link Columns. Although data can be passed in from the pop initiator, it cannot be automatically passed back at the end of the record. Data captured during the record can still be written out to a database or a web endpoint as usual, and Data Extracts are still able to access the data

 

2) Two-way: for this type of integration, data can be passed into the record on pop from the external record just as for the one-way type, but any changes made to Fields that have been linked to external record values via Link Columns will have that data automatically submitted back to the external system whenever the Page is navigated and/or when the record is finished. Commonly the data is only received at the moment of pop, rather than continuing to be updated throughout the time that the record is open. For some integrations, it may even be the case that any outcome or notes specified during the record are automatically submitted to the external record when the record is finished.

 

 

All pop attempts need to specify an Identifier, which will then be used to select the appropriate Workflow to pop. The Identifier can either be defined externally and linked to a Workflow via External Links, or created manually in the Campaigns Section.

 

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

 

A Reference is used to uniquely identify a record, and can also be used to cross-reference a record with an external source. When popping a Workflow, the Reference can either be specified as a desired value, or left blank to have a generic Reference in the form of CSAUTO-#-#-# automatically generated.

 

The value of the current Reference within a record is held within [var_csReference], and this can then be used as the specified Reference for a subsequent queued 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.

 

If the paired Reference and Identifier are reused, each pop will generate a new record run within the same record, sharing access to the same Field data within the Workflow.

 

Every record run exists within an Activity, and when popping a record 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 records will actually be popped, and also control access to any shared data.

 

All record runs within the same Activity will share access to a common Script.Data layer to allow data to be shared between the record runs in that Activity. This means that if two record runs are queued with the first retaining the current Activity and the second creating a new Activity, then the original record run and first queued record run will have access to the same data within Script.Data, whereas the second queued record run in the new Activity will only have access to any data specified as part of the pop invocation.

 

Multiple pops can be queued within a single record, 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 record run is exited. Specifically, all of the pops 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 pops popped in sequence, and then the second new Activity to be queued will be popped, and so on.

 

Within a record (inside Activity A, with Reference 1) we could queue up three 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 record is exited, the first record to be popped is actually the second that was queued; it is the earliest queued pop within the current Activity, and so is reached first. However, this record has a different reference to the original record, so despite sharing an Activity it won't have its data written back to the original record. As it shares an Activity with the original record, 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 record runs within the same Activity.

 

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

 

Finally, the last record run 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 record runs. It has a different Reference and is also within a different Activity, so the record 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 record runs in this example did.

 

 

Data can be passed into the Activity on pop, becoming available for any Fields configured with Link Columns. The Link Columns each match to any provided data keys in a case-insensitive manner, so all instances of that keyname in the Link Columns will take the value of the first case-insensitive matching key from the pop 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.