Interaction Designer - Queue Activity
Overview
A queue activity allows for the execution of an offer following its upstream queue listener’s receipt of data via a JSON package arriving on the listener queue (and the optional customization of the content therein based on the data thus received, using parameter attributes).
You can only attach a queue activity to a queue listener. A queue activity cannot be attached to more than one queue listener. You cannot add a queue activity downstream from another queue activity. You also cannot add any other activitites downstream from a queue activity.
Mini Toolbar
The following options are available in the mini toolbar when you select a queue activity:
View results: shows the Results Window, within which are displayed the queue activity’s results.
Show configuration panel.
Configuration Panel
A queue activity’s configuration panel contains General and Metadata tabs.
The General tab contains the following:
Mode: this dropdown exposes the following options:
Generate offer history: selected by default. When selected, the Audience definition property is displayed; on execution of the queue activity, a record will be added to the offer history table defined by the selected audience definition.
Don't generate offer history: when selected, on execution of the queue activity, an offer history record is not written. The Metadata tab is not shown when this value is selected.
Audience definition: this dropdown is only displayed when Generate offer history is selected. It lists only queue listener audience definitions. Other audience definitions are not shown. If a default queue listener audience definition has been selected, it is selected by default.
Qualification section, exposing a single property:
Qualification rule: this optional property allows you to specify that only incoming data targeted by a specified selection rule or realtime decision will be served the queue activity's configured offer. You can associate a selection rule or realtime decision with the queue activity. If required, you can initiate the creation of a new standard selection rule or standard selection rule placeholder.
When a qualification rule is applied to a queue activity, on the activity's execution, if a parameter passed within an incoming data packet matches the RPI Realtime Master Key or an Alternative Key, the profile of the visitor in question is loaded, and parameter values from the same are available for rule evaluation. Any incoming parameter values are saved to the visitor's profile, and are written to the current queue listener resolution table. In addition, if a parameter passed in matches a cached attribute list lookup name, the visitor profile's database values are loaded and available for evaluation at a database realtime decision.
Note that an Identity object can also be passed in to load visitor profile parameters (data from the same can also be written to the queue listener resolution table).
In addition, a Geolocation object can also be passed in the queue message to facilitate the making of geolocation decisions.
The Qualification rule is evaluated against the visitor profile. For example, if a selection rule was chosen, a visitor profile key must match a resolution key targeted by the rule for it to be satisfied. If a realtime decision was selected, it is evaluated against the visitor profile. Note that if identifying parameters are not passed, a qualification rule can be satisfied by its not requiring such - e.g. a Web realtime decision with a Day of the week criterion, or by a non-identificatory parameter being used to satisfy the decision.
If a Qualification rule is evaluated successfully, the queue activity's result count is incremented, and its offer is fulfilled to the recipient's send address. If not evaluated successfully, the count not incremented, and the offer is not fulfilled.
Note that you can change an active queue activity's Qualification rule by deactivating its parent queue listener, changing the property, saving and re-activating the queue listener.
Fulfillment section: exposing the following properties:
Offer: provision of an offer with which to configure the queue activity is mandatory (unless a Control channel has been selected). The selected offer must be valid. You can choose an offer by browsing, or by using drag and drop. The selected offer must support at least one non-broadcast delivery method. You can also initiate the creation of a new offer. Once an offer has been selected, you can open its latest version in the Offer Designer. You can also clear your selection. Note that a validation error will be raised in the event of selecting a data onboarding offer.
You can also configure a queue activity’s Offer property by dropping an existing RPI offer file from the toolbox directly onto a queue activity icon in the Interaction Designer workspace.
Offer Channel: this dropdown field lists only those channels supported by the currently-selected offer's delivery method(s). Broadcast channels are not shown. Note that you can select a Control channel without first selecting an offer.
The following channels are supported in the context of queue activities:
Eloqua email
LuxSci email
SendGrid email
SFMC email
SFMC data transfer
Twilio SMS
Salesforce.com CRM
Note that Salesforce.com channel's Allow update option is not applicable when executed in a queue activity.
Send address parameter override: this optional text field is blank by default. When set, it allows you to specify that another field in the supplied JSON payload will also serve as the payload's SendAddress. By attaching multiple queue activities to queue listener, each with different send address, you can fulfill multiple offers through the submission of a single JSON payload. Note that only a single row is added to the queue listener resolution table when you do so, with one offer history row per offer fulfillment/contact. The same resolution key is used for all offer history records.
The Metadata tab is shown when Mode is set to ‘Generate offer history’. It contains the following:
Activity Metadata Overrides: this section lists the metadata attributes defined at the currently-selected Audience definition. You can override values and revert to the defaults provided as required. Metadata values are written to a mode-specific Offer History Meta table on parent queue listener activation (one record per queue activity). If a queue listener is de-and re-activated, persisted metadata values are updated to reflect current values at the point of activation.