Skip to main content
Skip table of contents

Interaction Execution - Activity Executions

Offer Activity Execution

When an offer activity runs, fulfillment occurs in accordance with the offer activity’s specified channels.

Where an individual qualifies to be contacted by more than one channel, contact is made via the first applicable channel for which he or she qualifies. Channel applicability is determined by the channel’s filter. The filter is defined as a selection rule; if a record is targeted by a selection rule associated as a channel filter, that channel is deemed to be applicable for the record.

Results of the execution of an offer activity are written to the permanent offer history and offer history meta tables (the actual table names are defined by audiences’ audience definitions).

In addition, fulfillment activities take place in accordance with the channels’ delivery method. Each delivery method is documented separately.

Following execution of an offer activity, a results bubble is displayed to the top right of the offer activity icon. It shows a rounded summary of the number of records in the results set. Results are shown to a single decimal place, e.g.:

1,203,492 = 1.2M

75,854 = 75.9K

Full results are available in the Results Window.

Contacts made through a particular channel may be further restricted if the channel used has been associated with a filter. In this case, fulfillment will only take place in respect of those records that are targeted by the filter’s selection rule.

You can invoke Stop or Pause at an executing email, push notification, SMS, data onboarding or CRM offer. Having done so, you can Play the activity again. Any records previously targeted by the offer will not be targeted upon resumption of execution.

When the number of records targeted by an offer activity (or export activity configured to use a data extract channel) exceeds its channel's Targeted warning threshold, the activity enters a Paused state. This applies in both Test and Production mode. Log messages are written to advise as to why this occurred. If required, Channel Targeted Threshold Exceeded email alerts are sent. You can click Play at the activity to resume its execution. Note that a threshold check is applied per individual fulfilment occurrence - e.g. one specific email send within a recurring trigger.

If the offer's channel's Fail if no merge files property is checked, the workflow will fail when zero records are targeted, with the message 'No mail merge has been generated; sending will be terminated' being shown in the log.

If the channel is configured to call an external service post-execution, that service is invoked immediately upon channel execution. If an invalid service address was supplied at channel configuration, execution continues without failing.

If a channel is configured to call a Redpoint Data Management job post-execution, not that the job will be called when executed in both Test and Production mode.

Following production execution of an offer activity when offer approval is enabled, if you view the Completed offer’s configuration panel and drill through to the offer’s template, the version displayed is always the latest – even if a prior version was used at interaction execution.

Note – if executing an offer against a Google BigQuery data warehouse, and having applied offer metadata overrides at the interaction, the potential exists for lengthy delays to occur.

Data Extract

During data extract offer execution, files are created as per execution of an export activity and are made available at the RPI server, via FTP, or at an external content provider root folder.

A data extract offer produces files when executed in Production mode, or in Test mode when its channel’s Create files in Test mode property is checked.

By default, data extract files are created in accordance with system configuration setting FileExportLocation. Writing of files to a server folder, FTP site or external content provider root folder is supported.

If files are generated at the server, they are by default created in a sub-folder named in accordance with the following:

‘[(Global)FileOutputDirectory]\WFAI[WorkflowInstanceID]\Export files\[Export name]’

Where (Global)FileOutputDirectory is accordant with the configuration setting value defined at the cluster or tenant, Workflow Instance ID is the unique numerical identifier assigned to the workflow instance at its creation, and Export name is the name by which the data extract offer is known within the interaction.

Note that the default folder may be overridden if configured accordingly at the data extract channel.

When created at an FTP site or external content provider, ‘(Global)FileOutputDirectory’ is replaced by an ‘Export’ folder.

If configured to write to an external content provider, and no default file export provider has been identified, files are written to the RPI application server instead.

The resultant data and sample files are accordant with the export template with which the channel is configured; in addition, any extra attributes specified within the Offer Designer are appended within the output files.

If the data extract channel through which the offer is fulfilled is configured to allow duplicates on resolution, if the channel’s export template and/or the activity's offer is configured with any cross-resolution attributes, deduplication is ignored, and multiple records for a single resolution key can be output in the export file. Note that the activity's bubble count continues to reflect its deduplicated count.

On generation of an extract file in Test mode, Offer History and Offer History Meta attribute values are replaced with sandbox equivalents. Note that when the same tables are referenced as aggregation tables, sandbox values are not substituted.

If the channel’s export template is configured with a custom header, it is displayed in accordance with its definition. Any Record Count text parts reflect the full export file count.

Filenames are generated as GUIDs (Globally Unique IDs) unless explicitly defined at the channel.

Behavior of a data extract offer downstream from an interactive activity configured with an audience depends on its and its channel’s configuration. If the file to which data is to be written is local to the RPI server, rows are appended to the output file dynamically as they are targeted by the audience. If the export path has been specified, a new file is written at the arrival of new records.

If configuration setting InteractionDaysToPersistExportTempTables is greater than 0, the temporary table generated during offer activity execution is persisted for a number of days specified by the setting. This occurs both in Production mode, and in Test mode when Create files... is checked at data extract channel configuration. Persisted temporary tables can be tracked in the ExportTempTableLookup table, which can be found in the Interaction Audit database. The Dataflow housekeeper removes temporary tables, and matching rows from the table, after the specified number of days.

When PGP encryption is configured at a data extract channel, full export files generated using the channel are encrypted. Sample and summary files are not encrypted. PGP encryption is also applied when files are generated in Test mode, and when file compression is enabled.

If the offer uses the Database Table extract location, data is persisted within a data warehouse table in accordance the data extract channel’s settings. If using default channel settings, the table will be named ‘RPI_Export_[GUID]’ (the actual table name may be discerned within the offer’s execution log). If the table already exists, it is dropped and re-created. If a lengthy custom table name has been specified, it is truncated in accordance with the maximum number of characters permitted by the database. The table is deleted by RPI Housekeeping in accordance with the relevant Days To Persist Table setting.

Outbound Delivery

At Production execution of an outbound delivery offer, if Generate export file is checked at the channel, an export file will be generated in accordance with the channel and its export template settings. Note that values RPContactID and ChannelExecutionID are added at the beginning of each row in the export file. If Generate export file is unchecked, an export file is not generated. However, offer history records are written as expected.

If Use content was checked at the channel through which the offer is executed, additional files are created in accordance with the offer's content:

  • RPI_Export_[CHANNELEXECUTION_ID]_Content.txt

  • RPI_Export_[CHANNELEXECUTION_ID]_Source.txt)

Any pre-processed dynamic content is added at the end of each row in the export file, using the channel's configured Start and End tag delimiters.

The table used to import and process channel states data will be automatically created during execution of the channel sync task, with the following prefix:

RPI_ CDS_<GUID>

Once the import of states data is complete, the table will be dropped.

If the channel's Import state results via DM property is checked, channel state results can be collated as per the following:

A file containing state results can be placed in the folder defined by the channel's State results folder property, in order to be processed by the Redpoint Data Management job defined at the channel's RPDM Repository path. .txt and .csv file types are supported, and the structure of the state results file to be imported must match that defined at the Redpoint Data Management project. A header row is also required. Channel results are processed on execution of the Outbound Delivery channel's synchronization task, which is responsible for reading in delivery state data (in accordance with definition of the same at the channel). Once channel results have been processed, the file is deleted.

If Import state results via DM is unchecked, execution of the Outbound Delivery channel sync task does not result in collation of state results.

A sample Redpoint Data Management project is available at:

DeploymentFiles\DataManagement Macros\Channel Synch Loads\OutboundDelivery_v4.dlp.

The project can be customized to tenants' specific requirements.

If configured, Realtime in Outbound can be used to vary delivered content served by an outbound delivery channel.

Email

During email offer execution emails are sent to qualifying individuals only where a valid email address exists. Textual and HTML content are consistent with that defined within the Offer Designer, and any attributes included within the email template are resolved for inclusion within the body of the email.

The emails to be sent will depend on the email offer’s Content mode setting:

  • If set to Multi-part, both HTML and text emails will be sent.

  • If set to Text only, only text emails will be sent.

  • If set to HTML only, only HTML emails will be sent.

If an email offer has been defined to perform fulfillment at a specific scheduled time, on executing the offer in Production mode in advance of that time, it immediately assumes a Completed status. Emails are delivered later in accordance with the offer channel’s settings.

If the email offer’s channel's Recipient email field is populated with an attribute with a target table that is incompatible with any of its workflow's audiences , a warning message is displayed at workflow activation. For each email offer in the workflow, the following message is shown:

'An issue was encountered validating offer activity [activity name], Join not found between [audience table] and [email attribute table]'

When email execution takes place using an email channel, the system automatically de-duplicates on email address. One row is added to the Offer History table per pre-deduplication record. The Selected field in the Offer History table indicates whether a given record survived the deduplication exercise.

An external email service provider (ESP – Eloqua, LuxSci, SendGrid or SFMC) is responsible for sending the emails. If the channel has been defined as auto-suppressing, email addresses present in the email suppression table are not contacted.

If the connection to the ESP’s email service cannot be made, RPI repeats its attempt to connect every minute for 10 minutes before failing.

When an email offer contains an embedded asset, during recurring execution (in a recurring workflow or following an interactive activity), when the asset is updated, the latest version of the asset is included in delivered email content. The same applies at nested embedded assets.

You cannot execute an email offer in Production mode if it contains an image asset that is larger than the maximum permissible size defined by system configuration setting MaxEmailImageSize. Note that this setting does not apply if the images used are hosted (privately or publicly) at an external content provider.

If configured, Realtime in Outbound can be used to vary delivered content served by an email channel. For more information, please see the Smart Asset Designer documentation.

Use of the RPI Realtime service to personalize outbound messages is supported at the following email provider:

  • SFMC

  • Eloqua

  • LuxSci

If the email offer contains a URL, and the channel is configured with compatible Google Analytics or web events adapter, on traversing the link in the posted message, website activity can be tracked and monitored. This is carried out by the appending of query string parameters to the URL.

The following parameters are appended for a Google Analytics adapter:

  • utm_source

  • utm_medium

  • utm_content

  • utm_campaign

Any supplied meta tags are rendered appropriately.

The following parameters are appended for a Web Events adapter:

  • rpcid: RPContactID

  • exid: ChannelExecutionID

When an email offer is executed via a channel associated with one or more PURL adapters, URL parameters are appended to URLs with which web links in the email content are configured, in accordance with PURL adapter configuration.

If more than one PURL adapter is associated with channel, all URL parameters are appended. If a PURL adapter's Web Site URL is not set, parameters are appended to URLs in all links in the email content. If a PURL adapter's Web Site URL is set, parameters are only appended to URLs accordant with the setting.

Multiple parameters are appended in the order defined within the PURL adapter configuration interface. Parameter values are set to the value of the relevant attributes for the email recipient. Note that a validation error is raised at runtime if the attribute with which a URL is configured is incompatible with the audience definition used by an audience within the interaction workflow.

Note also that, if a link URL is sourced from an attribute value, the personalization thereof using a PURL adapter is not supported.

Following a hard bounce due to email undeliverability, a record is added to the email suppression table; its UnsubscribedMethod is set to ‘Hard Bounce’

If you invoke Stop at a Playing workflow that contains a Playing production email offer, and email data has been uploaded to the ESP, the offer is terminated as expected. However, emails will still be delivered, and state information will continue to be monitored for.

On receipt of an email sent via an email channel, if the email offer content was defined as for Marketing purposes, the following elements are automatically included:

  • 'To view this email as a web page, go here': this link is displayed above the email’s content. Clicking the link launches (a new tab within) the client application machine’s default web browser to display the contents of the email as a web page.

  • 'This mail was sent to: [recipient's email address]': displayed immediately below the email’s content.

  • ‘This mail was sent by [sender name and address]’.

  • One-Click Unsubscribe: clicking the link launches (a new tab within) the client application machine’s default browser to display the Unsubscribe Center.

  • Update Profile: clicking the link launches (a new tab within) the client application machine’s default browser to display the Subscription Center.

  • Manage Subscriptions

A runtime validation error is raised when a non-queue listener workflow contains an email offer fulfilled using an email channel without a Recipient email property.

At email offer execution, if the offer contains localized content, the attribute defined at the channel's Region/language code property is used to determine the localized content variant to be sent to a target.

The following RPI email service providers support use of an email offer's Reply-to Email property:

  • Eloqua

  • LuxSci

If an email offer sent using one of the above providers includes a Reply-to Email address, if Reply or Reply All is clicked in respect of a received email offer, the configured address will be used as the reply's 'To' address. If not configured, Sender email is used instead.

If sent using a provider that does not support Reply-to, a runtime validation error is raised at workflow execution. In the event of proceeding with execution, the default Reply-to address as configured at the email service provider account is used.

If a BCC email address has been set up at the email channel (and/or overridden at the offer), the following apply:

  • A runtime validation error is raised if the current channel provider doesn't support BCC and BCC was overridden at the offer.

  • One BCC email is sent to the BCC email address per delivered email, in accordance with the channel and offer settings.

  • Dynamic content variations are reflected in delivered BCC emails.

  • BCC emails are not sent if the supplied BCC email address is invalid.

  • If a contact is undeliverable, a BCC email is not sent.

On including a text asset containing a link with URL parameters in an email offer, on receipt of the same, parameter values are shown as 'X'.

Facebook Like Button

On receipt of an email containing a Facebook Like button, the button displayed is as per system configuration setting ButtonImageFacebookLike.

Clicking the button displays a web page in which is shown the content defined by the button’s Share property. The recipient may choose to Like the content at this point.

Facebook Page Button

On receipt of an email containing a Facebook Page button, the button displayed is as per system configuration setting ButtonImageFacebookVisit.

Clicking the button displays the Facebook page with which it is configured in the recipient’s default browser. He or she may then choose to Like or Comment as they see fit.

Alchemer Page Button

On receipt of an email containing an Alchemer page button, the button displayed is as per system configuration setting ButtonImageAlchemer.

Clicking the button displays the survey with which the button was configured in your default web browser.

Twitter Follow Page Button

On receipt of an email containing a Twitter Follow Page button, the button displayed is as per system configuration setting ButtonImageTwitterFollow.

Clicking the button displays the Twitter feed with which it is configured in the recipient’s default browser. He or she may then choose to Follow the Twitter user in question.

Twitter Tweet Button

On receipt of an email containing a Twitter Tweet Page button, the button displayed is as per system configuration setting ButtonImageTwitterFollow.

Clicking the button displays a Twitter login page in the recipient’s default browser. Having successfully provided credentials, a Post a Tweet on Twitter page, configured with the button’s tweet message and link URL, is displayed.

The recipient can click Tweet to post the tweet in question to his or her Twitter followers.

Facebook Share Button

On receipt of an email containing a Facebook Share button, a button is displayed therein.

Clicking the button displays a Facebook login page in the recipient’s default browser; having successfully provided credentials, a Share on Facebook page is displayed, allowing you to share the email content with your Facebook friends.

Twitter Share Button

On receipt of an email containing a Twitter Share button, a button is displayed therein.

Clicking the button displays a Twitter login page; having successfully provided login credentials, a Share a link on Twitter page is shown.

The tweet contents are set to a URL; on clicking Tweet, a message advises that your tweet has been posted, and provides the opportunity to view it on Twitter.

Clicking the link displays the shared cell or entire email in a separate browser instance.

ESP Considerations

The following considerations relate to a specific ESP.

  • SFMC:

    • When executing an email offer containing an embedded table asset in an Oracle environment, and when the channel's Import via file setting is checked, please ensure the channel's Disable field quote wrapping property is also checked.

    • The email’s Sender address must be validated at the SFMC Portal.

    • At execution of a SFMC email offer, the data extension and email objects' names thus created are preceded with the following:

‘[Interaction name]-[Activity name]-‘

If the interaction name is the same as the activity name, the objects are preceded with:

‘[Interaction name]’

If Encrypt exported file was checked at the channel, the export file generated at email offer execution will be encrypted in accordance with the specified public key and encryption type. Execution will fail if the key is not valid. If encryption is successful, the encrypted file is uploaded to SFMC with the following file naming conventions:

[GUID].csv.pgp/gpg

If the channel's File transfer activity name property is valid, the file is decrypted and data loaded into the SFMC data extension.

At channel synchronization Task execution, if the channel's Decrypt imported file property is checked, the supplied Tracking extract activity name is used to generate disposition data. The supplied File transfer activity name is used to encrypt disposition data which is saved in accordance with the channel's configuration. Saved files are downloaded and decrypted using specified the Encryption private key, in accordance with the selected Encryption type. If the specified key is not valid, the file import process fails.

  • Eloqua: the following are not supported:

    • Use of nested smart assets in email content.

    • Use of table smart assets in email content.

    • Custom attribute formatting

    • Dynamic sender

    • Dynamic reply-to name

    • BCC address list

    • size channel configuration settings.

  • LuxSci

    • LuxSci unsubscribe data are received by RPI, and are loaded into the email suppression table.

    • Offer execution will only fail when all of a batch of emails fails to send.

    • A tracking record will be inserted into the RPI_LuxSciTracking table when at least 1 email is successfully sent.

    • Luxsci supports execution in 'sandbox mode'. Sandbox mode is enabled in the Execution Service configuration file (Resonance.ExecutionService.exe.config) as per the following example:

CODE 
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
    <section name="RedPoint.Resonance.ChannelPlugins.LuxSci.LuxsciSilentSettings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
<applicationSettings>
    <RedPoint.Resonance.ChannelPlugins.LuxSci.LuxsciSilentSettings>
        <setting name="EnableSandBoxMode" serializeAs="String">
            <value>True</value>
        </setting>
    </RedPoint.Resonance.ChannelPlugins.LuxSci.LuxsciSilentSettings>
</applicationSettings>

When enabled, messages are validated, accepted, and queued for sending within LuxSci but are not sent to recipients.

  • During LuxSci channel results synchronization, when Import via file is checked at the channel, the following occurs:

    • RPI makes an asynchronous request to export email events to the selected Report destination.

    • Table 'RPI_LuxSci_State[Import table suffix]' is created to persist the imported email state information.

    • An RPDM file import job is executed to update the email state information.

  • At activation of a workflow containing a LuxSci email offer, if the combined length of system configuration setting FileOutputDirectory, offer activity name, and channel name exceeds 180 characters, a runtime validation error will be raised.

Forward to a Friend Button

When viewed in delivered email, a Forward to a Friend button is shown using the image configured via system configuration setting ButtonImageForwardToFriend. Clicking the button displays a Forward to a Friend page, tailored for your organization, in your default web browser.

The page contains the following:

  • 'Forward your email to a friend...'

  • 'Recipients' Information'

  • 8 sets of: Name, Email

  • Type your message here, Your name, Your email address ([Email address to which mail originally sent)

  • Submit button: invocation sends mail to recipients in list.

On receipt, a forwarded mail contains the following:

'Hello [Recipient Name]

[Sender Name] has forwarded the following email to you with this message:

[Message]

To view this email as a web page, go here.

[Original message content]

SFMC Data Transfer

At execution of a SFMC data transfer offer, details of the individuals selected in upstream audiences are passed to SFMC. For each such contact, the attributes configured at the Email Data Transfer offer are transferred.

If Append to existing was not checked at the offer, a new data extension, named as per the offer, is created at SFMC. If the offer is executed within a recurring workflow, an incrementing integer is appended to the data extension’s name, ensuring its uniqueness.

If Append to existing was checked at the offer, behavior is dependent on the offer’s Update type setting:

  • Add only – only adds new records and does not update the data of existing records.

  • Add and update – add new records and updates data of existing records.

  • Update only –updates data of existing records, does not add new records.

  • Overwrite – deletes any existing records and then adds new records.

If Encrypt exported file was checked at the channel used by a SFMC data transfer offer, the exported file will be encrypted using the specified public key, using the selected encryption type. If the specified public key is not valid, the workflow will fail.

If encryption is successful, the encrypted file is uploaded into the Enhanced FTP location with the following file naming convention:

'{guid}.csv.pgp/gpg'

If the Salesforce File transfer activity is valid, the file decryption process is initiated, and data imported data into the data extension specified in the SFMC data transfer offer. Otherwise, the workflow fails.

You can then log into the SFMC user interface in order to execute a campaign using the data provided by RPI.

At channel synchronization task execution, if the channel's Decrypt imported file option was checked, the value supplied at Tracking extract activity name is used generate disposition data. The channel's File transfer activity name is used to encrypt disposition data and save into SFTP Export directory. Files available therein will be downloaded and decrypted using the specified Encryption private key, in accordance with the selected Encryption type. If the supplied key isn't valid, the file import process will fail.

Please note the following limitations:

  • No option exists to create the automation via the SFMC API so it will need to be created manually (it will be called using the external key).

  • No option exists to override the date range on the data extract activity using an automation, so it will need to default to a set period. Data will thereafter be deduplicated at insert.

Twilio SMS

The SMS message as defined within an SMS offer is sent to recipients when executed in production mode. SMS messages are not sent in Test mode.

The message as defined within the offer is sent to a queue defined by channel settings Personalized content queue and Personalized content queue path. Messages on the queue are sent to Twilio for dissemination to recipients' devices. Note that the queue is not used at execution via a queue listener.

Any invalid numbers are ignored.

If a URL shortener web adapter is associated with the SMS offer or channel, any URLs in offer content are shortened appropriately.

Twilio supports the sending of up to 10 image assets as an MMS message. Any image assets included in offer content will be uploaded to the web publish site configured at the Twilio SMS channel. If more than 10 image assets are in the offer, a runtime validation error will be thrown, and execution may not proceed. If a web publish location has been selected at the Twilio SMS channel, a runtime validation error is also thrown.

At SMS offer execution, if the offer contains localized content, the attribute defined at the channel's Region/language code property is used to determine the localized content variant to be sent to a target.

Post-execution, SMS results are displayed at the offer’s results bubble and are available at the Results Window. The fulfillment states supported by the channel are:

  • Duplicates: the number of duplicate records

  • Targeted: the number of records sent to Twilio, rather than number of SMS messages sent successfully

  • Queued: the number of records that are queued for sending. When all messages have been sent, this value is returned as 0.

  • Sending: the number of records dispatched to the nearest upstream carrier in the network. Provision of this metric is dependent on the count being returned by the carrier.

  • Sent: the number of records successfully accepted by the nearest upstream carrier. Provision of this metric is dependent on the count being returned by the carrier.

  • Delivered: the number of records confirmed as delivered by the upstream carrier. Provision of this metric is dependent on the count being returned by the carrier.

  • Undelivered: the number of records not delivered to recipients.

  • Failed: the number of records not sent and not charged to the account. Provision of this metric is dependent on the count being returned by the carrier.

  • Invalid Numbers: the number of invalid numbers, which were not contacted during SMS offer execution.

The result shown at the offer’s bubble and in the Count column in the Results Window reflects the count of records prior to de-duplication (duplicate numbers are not sent to Twilio).

If the connection to the Twilio SMS service cannot be made, RPI repeats its attempt to connect every minute for 10 minutes before failing.

Records with null phone numbers are not sent to Twilio. Records with invalid phone numbers are sent to Twilio but will not be sent to recipients. Note that country codes should be included with phone numbers when sending an SMS offer using a Twilio SMS channel.

Any messages intended for phone numbers in the SMS suppression table are not sent.

Note that Twilio does not support an opt-out capability.

On receipt of an SMS message delivered via Twilio, any attributes in the message are substituted with their appropriate values.

If the SMS offer's Mobile Messaging Type is set to MMS, up to 10 images can be included in offer content (a runtime validation error is raised if this number is exceeded; if ignored, only the first 10 images in content are sent). Only jpeg, jpg, gif, and png files, with a maximum size of 5Mb, are accepted by Twilio. Images are uploaded to the external folder defined at the Twilio SMS channel. External images are passed to Twilio using their public file URL. Similarly, if the channel's MMS upload folder property is not set, a runtime validation error will also be raised (ignoring the same will result in messages not being sent). Upon message receipt, images are displayed first within the same, irrespective of their placement within the offer.

Azure Push Direct Notification

When an Azure Push Direct Notification offer is executed in production mode, the message as defined within the offer is sent to a queue defined by channel settings Personalized content queue and Personalized content queue path. Messages on the queue are sent to the Azure Notification Hub for dissemination to recipients' devices. Note that the queue is not used at execution via a queue listener.

Messages are not sent in Test mode. One row is added to Offer History per contact, and messages are de-duplicated by Recipient address. Post-execution, results are displayed at the results bubble and are available in the Results Window.

Realtime Cache

When you execute a realtime cache offer in Test mode, data is not posted to the RPI realtime cache.

When you do so in Production mode, the data output by the offer is stored as cached attributes in the realtime cache. If multiple data values are returned for an attribute, only one value is persisted in the cache. NULL values are not persisted in the cache. Any attributes that appear more than once in the offer are ignored. If an attribute already has a value in the cache, it is refreshed with the latest value.

The realtime cache channel's Key attribute is used as a lookup to a visitor's ID. If a visitor was identified at the time of the offer's execution, cached attribute values are merged into the existing visitor profile. If the visitor was not identified, cached attribute values are written to a new profile. This profile can be merged with a visitor's existing profile at the point of their being identified by RPI.

You can execute a realtime cache offer in a queue activity. When you do so in Production mode, data is posted to realtime cache, with the key being identified either using a parameter attribute with a name matching that of the realtime cache channel's Key attribute being contained within the JSON packet or using the packet's SendAddress property.

Note that, if a realtime cache offer is executed in a queue activity in in Test mode, data is posted to the realtime cache.

Note also that rolling back a production realtime cache offer workflow does not remove its data from the realtime cache.

Facebook Audience Data Onboarding

On execution of a Facebook Audience offer, the activity undertaken depends on the offer’s Facebook action setting.

If set to Custom Audience:

  • Facebook users are sourced from the RPI data warehouse.

  • If the offer’s Mode of operation is set to Create new list, users are added to a new custom audience. If the name of the new custom audience already exists, a new audience is not created.

  • If the offer’s Mode of operation is set to Append to existing list, users are added to the existing custom audience.

  • If the offer’s Mode of operation is set to Delete from existing list, users are deleted from the existing custom audience.

Note that it may take a number of days for Facebook to complete matching for the uploaded custom audience.

If set to Offline Event:

  • On execution of a Facebook Offline Event offer, if Use existing is unchecked at the Facebook Offline Event offer, a new offline event is only created when a matching event does not already exist.

  • When Assign to Ad account is checked at the offer, the event is updated to assign tracking and read permissions to the Ad Account specified at channel configuration.

  • Users are then added to the specified event.

  • Note that a Facebook Offline Event channel’s User ID property is not required if executing a Facebook Offline Event offer using a queue activity.

  • If using Limited Data Use mode, the following data processing options parameters are added to the event data uploaded to Facebook:

    • "data_processing_options": ["LDU"],

    • "data_processing_options_country": 1,

    • "data_processing_options_state": [Equivalent US states data processing code]

If not, the following parameter is uploaded:

"data_processing_options": []

Note that any temporary files generated during execution are written to the folder defined by system configuration setting FileOutputDirectory.

Note also that RPI will only hash data when uploading data to Facebook when the channel's Pre-hashed data option is unchecked.

Google Ads Customer Match Data Onboarding

At Google Ads Customer Match offer execution, if the offer's Mode of operation is set to 'Create new list', a new audience list with the specified name is created in the Google Ads account. If a list with the same name already exists, it is used instead of creating a new one. Records are then added to the list. When Mode of operation is set to 'Append to existing list', records are added to the audience list specified at the offer. Google Ads ignores records that are already in the list. When Mode of operation is set to 'Delete from existing list', records are removed from the audience list specified at the offer. Google Ads ignores records that are not in the list.

Successful uploads will add rows to the OfferHistory_GoogleAdsCustomerMatchTracking data warehouse table. Its structure is as follows:

  • Audience List ID: the ID of the audience list where the record was inserted/removed

  • Channel Execution ID

  • Date Sent

  • Channel ID

  • Contact Info: pre-hashed value of the email or phone number, or non-pre-hashed value of third-party ID or mobile device ID

  • First Name

  • Last Name

  • Country Code

  • Postal Code

  • City

  • State

Salesforce.com CRM

When you execute an offer activity based on an offer that supports the Salesforce.com delivery method, the actions undertaken at Salesforce.com largely depend on whether the offer was defined as creating a new Salesforce campaign.

If the offer was configured to create a new campaign, a new Salesforce campaign is created using the Salesforce credentials defined at the channel. Its default properties are as follows:

  • Campaign Name: the campaign’s name is as defined at the offer. If an identically-named campaign already exists at Salesforce.com, a new one with the same name is created alongside the original.

  • Active: checked

  • Type: ‘Other’

  • Status: as per the offer

  • Start Date as per the offer

  • End Date: as per the offer

The campaign’s other properties are not set.

The leads or contacts targeted by the offer are uploaded to the new Salesforce campaign.

RPI checks as to whether the targeted leads/contacts already exists in Salesforce using the lookup keys configured at the Salesforce channel. Any records that do not match are created as new leads/contacts at Salesforce.

Lead/contact properties are accordant with the Field parameters mapped at the Salesforce.com channel. Note that raw database values only, and not translated values, are uploaded. Note also that Lead status and Lead source values are provided by offer content, not by the channel.

If the offer was configured to upload leads or contacts in respect of an existing Salesforce campaign, they are uploaded to the campaign selected at the offer.

A system pulse is generated on successful execution of a Salesforce.com offer:

'[n] lead(s)/contact(s) has | have been uploaded via channel [Channel Name] as part of offer 'Offer Name' by activity 'Activity Name' in interaction 'Interaction Name'

If Allow updates is checked at the channel, behavior at execution of the channel’s synchronization system task is accordant with the channel’s Update behavior setting.

  • If set to Sync from Salesforce to RPI Data Warehouse, at every channel synchronization, RPI updates the data warehouse using data from the Salesforce lead/contact records.

  • If set to Sync from RPI Data Warehouse to Salesforce, at every synchronization, RPI updates Salesforce Lead/Contact records with data from the data warehouse.

If Salesforce data to sync was set to ‘Leads’, a system-generated table is created for leads with the naming convention RPI_SFLEAD[Lead_table _name][ChannelID], and new Salesforce leads’ details are stored therein.

If Salesforce data to sync was set to ‘Contacts’, a system-generated table is created for contacts with the naming convention RPI_SFCONTACT[Contact_table_name][ChannelID], and new Salesforce contacts’ details are stored therein.

Column definitions are based on the channel’s Field parameters mapping configuration.

If, when synchronizing Salesforce changes back to RPI, data truncation occurs (for example, if a value entered into a field in Salesforce.com is of such an excessive length that it will not fit in its mapped field in the data warehouse), the data in question is not written to the data warehouse, and a server error is raised.

Also at channel synchronization occurs the writing of RPI contact history data to Salesforce.com. Initial invocation of the task post-execution of a Salesforce offer writes details of all other contacts made with leads since the initial Salesforce channel execution to Salesforce.com. Subsequent invocation writes any new contact history to Salesforce.com. Contact history records are visible at Salesforce as Activity History. Note that this applies to email, SMS and data extract offer execution only.

When a Salesforce activity history record is created in this way, it has the following properties:

  • Subject: ‘Email’, ‘SMS’ or ‘Data Extract’

  • Email: the lead or contact’s email address (if fulfillment occurred via an email channel and the Email field parameter was mapped and also configured at the Salesforce.com user interface).

  • Phone: the lead or contact’s cellphone number (if fulfillment occurred via an SMS channel and the MobilePhone field parameter was mapped and also configured at the Salesforce.com user interface).

  • Comments: ‘[OfferName] via Channel [OfferChannelSubName] on [TimeStamp]’

  • Status: ‘Completed’

Salesforce.com CRM – Accounts

When a Salesforce.com offer is executed using a channel at which the Data to Synchronize property is set to Accounts, the following apply:

  • One or more Accounts are added as Campaign members.

  • Salesforce data fields are created at the following Salesforce objects:

    • Account

    • AddressKey__c

    • ChannelExecutionID__c

    • ClientID__c

    • ExecutionID__c

    • RPContactId__c

    • CampaignMember

    • RPIAcctRefID__c

    • RPIExtID__c

  • The following additional offer activity log messages are generated:

    • '{x} Accounts out of {y} in file '{file_name}.xml' have been uploaded as Campaign Members on campaign with ID 'z''

    • 'Uploading 'Account' Campaign Members'

    • 'Preparing for 'Account' Bulk Upload'

    • 'Setting custom fields default permissions'

    • 'Creating custom fields for 'CampaignMember' object'

    • 'Creating custom fields for 'Account' object'

Control

When an individual is targeted via a Control channel, records are created in offer history tables, but no fulfillment action occurs.

Decision Offer Activity Execution

When a decision offer is executed, the rules configured therein are used to determine which of its test offers is the winning offer.

It is important to note that it is not the raw number of records matching a given fulfillment state that determines the winning test offer. Rather, the number of records in a given state as a proportion of the records targeted by the test offer is used to decide which is the winner. This allows you to target test offers at data sets of differing sizes and use their relative efficacy as the medium through which to determine the winner.

Having determined the winning test offer, a decision offer then fulfills that offer to its own input data set (which must differ from the data sets at which its test offers were targeted).

If it was not possible to determine a winning test offer (e.g. in the event of a tie), the default test offer, as defined at the decision offer’s configuration panel, is fulfilled by the decision offer. If a default offer was not specified, a test offer is picked at random.

Broadcast Activity Execution – Azure Notification

When you execute a broadcast activity configured with an Azure Notification offer in production mode, the message therein is pushed to all devices (Apple iOS, Windows and Android) registered with the channel’s Azure notification hub via a custom app.

If the offer is configured with one or more tags, and devices registered using a tag from the list will receive the notification. If a device is not registered with a tag, it does not receive the notification.

The set-up of custom mobile applications to support the receipt of Azure Notification push messages is beyond the scope of this documentation. For further guidance, please contact Redpoint Support.

Subscription Group Activity Execution – Alchemer

When you execute an Alchemer subscription group in production mode, it enters an Activated state. Its bubble count represents the total number of respondents to the related survey.

If the channel was configured to import survey data, on retrieval of the same when executing the channel’s synchronization task, survey data is imported into the following database tables (which are created at initial data import):

  • RPI_SGSurvey_{Survey table name}

    • SurveyID

    • Title

    • Status

    • DateCreated

    • DateModified

    • ResponseCount

    • TestResponseCount

  • RPI_SGSurveyQuestion_{Survey table name}

    • SurveyId

    • QuestionId

    • Question (truncated if > 4000 characters)

  • RPI_SGSurveyOption_{Survey table name}

    • SurveyId

    • QuestionId

    • OptionId

    • Option (truncated if > 4000 characters)

If the channel’s Survey table name is changed, existing tables are retained and a new set of tables are created.

If the channel was configured to import respondent data, the same stipulations around table creation apply, with data being imported into the following set of tables:

  • RPI_SGRespondent_{Respondent table name}

    • ResponseId

    • SurveyId

    • Status

    • RPContactId

    • ChannelExecutionId

    • DateSubmitted

    • STD_Referer

    • STD_UserAgent

    • STD_IP

    • STD_Long

    • STD_Lat

    • STD_GeoCountry

    • STD_GeoCity

    • STD_GeoRegion

  • RPI_SGResponse_{Respondent table name}

    • ResponseId

    • SurveyId

    • QuestionId

    • OptionId

    • Answer (truncated if > 4000 characters)

If the channel was not configured to import survey and/or respondent data, the related steps are not performed at channel synchronization task execution.

Seeds Execution

When a channel is configured with seed groups, seeds are applied to the channel output where seed column names match the output’s attribute names. How this comparison is made is dependent upon the context:

  • Offer data extract channel: compared against export template attributes and attributes defined at the offer.

  • Offer Email: compared against email address and attributes embedded in offer content.

  • Offer Control: seeds not supported

  • Broadcast: seeds not supported

  • Export: seeds not supported

  • Control: seeds not supported

Note that matches are not case sensitive. Where an attribute name contains a character that is not database compatible, that character is replaced by an underscore when performing the comparison against the seed column name.

Seeds are inserted at regular intervals in data extract export files in accordance with the number of seeds and the number of export records.

If no records are targeted by the activity, no seed fulfillment occurs.

Seeds can also be appended at audience execution, if configured at a batch audience or interactive activity configured with an audience . Note that audience-appended seeds are overridden by any downstream fulfillment activity seed assignment.

Downstream Post-Fulfillment Activity Execution

During execution of an activity that is downstream from another fulfillment activity, any records output by the preceding activity that match the inputs selected in the current activity are targeted. These include records in the following states:

  • Targeted state: selected by default when configuring the downstream activity, Targeted represents all records output by the upstream activity.

  • Email service provider-supplied states (e.g. Click Through). Note that, when a recipient clicks multiple URLs within an email, this counts as single Click Through.

  • Any custom fulfillment states defined for the channel.

  • Any combination of the above

Note that, if you select multiple states, the downstream activity will occur where records satisfy state A OR state B. Also, for a record to be counted as in a state, it must also satisfy the cumulative rules associated with all ancestor states (for example, a state flow might define a state of ‘Applied’, followed by child state ‘Accepted’; for record to qualify as Accepted, it must also satisfy the rules that define Applied).

Queue Listener and Activity Execution

On activating a queue listener, it enters an Activated state (following temporary assumption of a Waiting for Trigger state). Its configuration panel's properties are read-only when Activated.

When Activated, a queue listener begins monitoring the listener queue for the arrival of JSON packages that include a reference to its Listener key. Such packages may be placed on the queue by a third party, or via the submission of an RPI web form.

The JSON package format is as per the following example:

CODE 
{
'TriggerKey':'5df1c3d2-fc20-419c-8462-982e7769524a',
'SendAddress':'jim.hinder@Redpoint.net',
'Parameters':
    {
     'FirstName':'John',
     'LastName':'Smith'
     },
'RepeaterParameters':
     [
         {
         'OrderTitle':'Purchased',
         'ParamProductName':'Product X',
         'ParamProductValue':'9.99',
         'ParamProductDate':'04/07/2016 00:00:00'
         },
         {
         'OrderTitle':'Purchased',
         'ParamProductName':'Product X',
         'ParamProductValue':'9.99',
         'ParamProductDate':'04/07/2016 00:00:00'
         }
     ]
}

Please note the following:

  • TriggerKey must be set to the required queue listener's Listener key GUID value.

  • If the posting of the JSON package to the queue is to initiate the sending of an email, the recipient's email address must be supplied as the SendAddress.

The Parameters section represents data that is to be substituted at parameter attributes (e.g. contained in email offer content). The names of the passed parameters must match the names of the parameter attributes to be substituted.

The RepeaterParameters section is used to pass details of repeating entities that are to be output in offer content. For example, you might want to send a customer a confirmation email listing the products that they purchased. You can pass the products' details in the RepeaterParameters section, then include parameter assets representing the same in a table asset in the email offer they are to be sent.

Queue listener repeater parameters, as defined at a queue activity’s audience definition, are stored in a data warehouse table named ‘[Queue listener resolution table name]_RP’. For more information, please see the Audience Definition section in the Configuration documentation.

Any packages for the attention of a specific queue listener that are placed on the listener queue when the queue listener is in a Deactivated state are ignored.

The listener queue is checked every second for the arrival of JSON packages. Packages are processed in batches. The maximum number of records that can be processed in the same batch is defined by cluster system configuration setting ListenerQueueMaxBatchSize. For example, if 9 records arrive on the queue, and ListenerQueueMaxBatchSize is set to 5, 2 batches (1 of 5, 1 of 4) are processed.

Upon a queue listener's receipt of a JSON package with a matching Listener key, any downstream queue activities are executed. Such packages may be placed on the listener queue by an external system, or through submission of an RPI web form that has been configured with an interaction and queue listener.

When a queue listener's Realtime Event section has been configured, on the occurrence of a realtime event, and subsequent execution of the Web events importer system task, the queue listener will fire if the type of event matches the listener's configuration, with any Event detail filters applied and all matches at specified event metadata. Any parameters defined in the QueueListenerConfiguration, as sourced from the visitor profile, will be available to the queue listener (these can be used e.g. to personalize content, or can be written to the queue listener resolution table). If a subsequent appropriate event occurs in respect of a specific individual within the duration defined by the Prevent repeat sends for property, the queue listener does not fire.

When you execute a queue activity in Production mode, data from the JSON package's parameters is written to the queue listener resolution table, as defined by the queue activity's audience definition. To be stored in the queue listener resolution table, the name of a passed parameter must match the name of the column in that table (in turn defined by the audience definition's Queue listener attributes. When a column value is not supplied, the parameter attribute's default value is written to the table instead. When the package contains a parameter not in the resolution table, it is ignored. When resolution table structure has been changed, any legacy column values are set to NULL.

If offer content contains a non-parameter attribute with a name matching that of a passed parameter, the parameter value is substituted.

If a queue activity's Generate offer history radio button is selected, a record is written to offer history; If Don't generate... is selected, an offer history record is not written.

If a queue activity is configured with an email offer, an email is sent to the SendAddress recipient using the selected channel's email service provider (note that this takes place after offer history has been written). Any parameter attributes are substituted in email offer content (including any RepeaterParameters to be output within embedded table assets).

If the offer with which a queue activity is configured is edited, its new version is picked up only when the queue activity's queue listener is de- and re-activated.

When you execute a queue activity in Test mode, data is not written to the queue listener resolution table. If the queue activity is configured to write data to offer history, data is written to the offer history sandbox table defined by its audience definition. If configured with an email offer, note that emails are sent when a queue activity is executed in Test mode. If configured with a data extract offer, only the full export file is generated (the channel's Create files in Test mode property being ignored).

On deactivating a queue listener, it once again enters an Inactive state. Any downstream queue activities are also Deactivated. Having deactivated a queue listener that was executing in Production mode, you can re-activate it. You can also make changes to an existing queue activity's properties, including its offer, when Deactivated. Note that you cannot add additional queue activities to a Deactivated queue listener.

If a downstream workflow uses a queue listener workflow as an input workflow, the input workflow must be executed in the same mode. Any activities in the downstream workflow act upon the records sourced from the queue listener workflow. You can execute a downstream workflow irrespective of the current queue listener workflow's status. Note that, if activities in the downstream workflow are to make use of the records gathered by the queue listener, they can make use of the appropriate queue listener resolution level to facilitate their targeting.

On submission of a web form at which a Queue listener interaction and workflow is selected, a JSON package is automatically placed on the listener queue and is picked up by the queue listener with which the web form is submitted. Any queue activities downstream from the queue listener are fulfilled.

If such a queue activity is configured with an email offer, the email is delivered to the email address as submitted in an Email form element. If any web form element parameters are included in the email offer's content, the values submitted in the web form are substituted. If the web form does not contain an Email element, emails are unable to be delivered (the queue activity's Log, as displayed in the Results Window, advises of this fact).

You can execute a Post-channel execution web service following execution of a queue activity offer. HTTP Post/JSON and RPDM Web Service calls can be made. SOAP Web Service calls are not supported in this context, and any such channel settings are ignored.

If configured, Realtime in Outbound can be used to vary delivered content served by a queue activity.

You can pass JSONPath parameter attributes in the Queue endpoint body as parameters or repeater parameters. A custom JSON object must be passed in the body (if using repeater parameters and the RepeaterParameters array is used, the object is ignored). All JSONPath repeater parameters must be sourced from the same JSON array. For more information, please see the Attributes documentation.

Audit Files

When a fulfillment activity that sources its data from an audience based on an audience definition that is configured to produce audit files is executed, audit files may be generated. One or more audit files are generated if the current mode of execution matches the audience definition’s audit export configuration setting. A separate audit file is generated per channel.

Audit files are generated in a subfolder at a location defined by system configuration setting FileExportLocation, within an initial ‘WFAI’ (workflow instance ID) subfolder.

Each audit file is named as follows:

‘[Fulfillment activity name]_[Channel Execution]_[Wave ID].txt’

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close