Journey Builder Contact Re-entry

Please find below the findings of a recent investigation into Journey Builder Contact re-entry – where the concurrent journey injection relates to child records such as Opportunities or Purchases.

Problem

Where Journey Entry occurs at a Child-object level (Opportunity, Case or Purchase as examples), a given Contact may enter a Journey multiple times; the journey injection relates specifically and exclusively to the child record not the parent Contact.

When Contact Data attributes are referenced (by filter expressions) across one-to-many relationships there are no implicit filters applied that ensure that only the relevant Child-object record is referenced, i.e. the record that initiated the journey entry. Instead the first Child-object record (related to the Contact) that passes the filter conditions for a configured path will be utilised. This means that any child record (for the Contact) could drive the flow through each decision split within the Journey.

Solution A. Salesforce Data Events

Note, auto-generated Data Extensions related to Salesforce Data Event Entry Sources are created with all fields set to nullable, apart from the Primary Key (Primary Object ID).

A.1 Id field on the related Salesforce (Child) Object is the Foreign Key to the related Contact Data.

e.g. Entry Source = Purchase Data Extension (PK is Purchase Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can go ID field to ID field with an attribute to attribute comparison (which requires non-nullable fields).

In Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Object ID field (Primary Key)

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.

A.2 Non-Id field (other relationship field) on the related Salesforce Object is the Foreign Key to the related Contact Data.

e.g. Entry Source = Payment Data Extension (PK is Payment Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can’t go ID field to ID field instead the nullable FK field Purchase__c is the key into the Contact Model; being nullable an attribute-to-attribute comparison won’t work.

Link the auto-generated Entry Source Data Extension to the related (Synchronised or Standard) Data Extension with a new relationship in Contact Builder (Data Designer > Sales and Service Cloud Attribute Group).

In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > Event Source DE > Primary Object ID field

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters by selecting the Entry Source DE and navigating the new relationship added to the Synchronised Data Extension.

Solution B. Automation Studio Audience

In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Foreign Key field (Could be the Primary Key field or any other field that holds the foreign key identifier value)
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Key field (i.e. Primary Object ID)

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.

Additional Considerations

1) Journey Data returns the specific Entry Source DE record that initiated the Journey and provides the only means to establish a fixed reference for this record into Contact Data.
2) Exit Criteria can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level.
3) The Update Contact Activity can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level. This activity will update all child records for the current contact in the target data extension.

Salesforce Marketing Cloud January 2017 Release

icon-cloud-marketing

This post marks the first Salesforce Marketing Cloud related post on this blog, an event reflective of the increasing number of Salesforce implementations that span both the Salesforce and Marketing Cloud platforms (or cross-cloud, a term I can’t seem to stop using). Architects working on such implementations require a solid understanding of Marketing processes and both the functional and technical composition of the Marketing Cloud platform – not to mention the various APIs, connectors and 3rd party solutions offered via the HubExchange. Such a grounding is necessary to allow business processes (that are incidentally cross-cloud) to be understood and optimally implemented. This point is key; in ideal terms marketing processes should be integral parts of wider/deeper business processes that touch upon multiple areas of the business in pursuit of better customer experience or engagement. This type of thinking is key to realising current industry trends such as “Continuous Experience” where classic organisational structures (sales, service and marketing operations) are abandoned, or diminished, in favour of delivering unified customer journeys across all touch-points. For architects tasked with delivery of such solutions, the challenge starts with marketing domain knowledge and Marketing Cloud practitioner insight. In my own recent experience both stated aspects can benefit greatly from the combination of website/blog trawling, Trailhead and certification (Salesforce Certified Marketing Cloud Consultant). I completed the two required exams for this certification recently and found the experience challenging and time consuming but ultimately rewarding and definitely something I’d recommend to all Salesforce architects.

And so, on to the actual topic for this post – a review of the key features within the first of five major releases for the Salesforce Marketing Cloud scheduled for 2017.

The release notes are available here. The release is due to occur on the 27th January – this of course is subject to change.

– features are GA if not indicated otherwise

Marketing Cloud Connect – Sales & Service Cloud Activities
The ability to create Salesforce Activity records within a Journey Builder definition is now more intuitive via a new Lightning UI that abstracts the complexity of the WhatID/Who Id model for relating Activity records to Leads, Contacts and related records. Salesforce record interactions from within Journey Builder are key to blending the power of the two cloud platforms.

Content Builder – Themed Templates
Email messages can now be created from Themed Templates that encapsulate best practice for content creation. The templates provided cover Financial Services, Retail, Restaurant and Newsletter scenarios. The Themed Templates options can be found in the Define Properties step of the content creation flow.

Journey Builder – History Tab
The Contacts tab in the main Journey Builder navigation has been replaced with a History tab that displays the status of running journeys along with failure reasons to aid troubleshooting.

Marketing Cloud Mobile App
The January release brings an Android version of the mobile app and a new home dashboard for the iOS version. The Android version exhibits the same Lightning Experience UI and can be downloaded from the Google Play Store. The new app version will be released 2 weeks approximately after the main release date subject to Google/Apple app review. The new home page for the iOS version of the mobile app supports daily or weekly reminders and the delivers key performance statistics plus the current status of marketing automations. Note, the reminders work as push notifications and appear as badges on the app icon (as per email, SMS messages etc.). The new version of the iOS app also supports SMS campaigns via the SMS button in the primary navigation.

Social Studio – Emoji Support
Emojis come to life in the January 2017 release. The Publish component now supports the use of social network specific emojis within social content creation via the Emoji Picker (Composer and Inspector). Emojis are also correctly rendered by Engage and can be used to infer sentiment within Analyze thereby increasing accuracy.

Social Studio – Facebook Reviews
Social Studio now provides features to manage the reputation for a local Facebook page. Facebook reviews can be organised to filter promoters from detractors, automated actions can also be triggered based on review score. For example low scores could invoke a Journey Builder journey or Service Cloud case. Powerful stuff.

Social Studio – Analyze Dashboards
The Analyze component of Social Studio receives significant enhancement in respect to dashboards. The new release supports mixed dashboards showing content across multiple social accounts or topic profiles and expanded real time date options. Advanced card configurations enable filters, custom names and custom dimensions to be applied to individual cards within a dashboard.

Web Studio – Smart Capture to Lists
Previously Smart Capture Blocks defined within Content Editor were limited to Data Extensions for data push, with the January release this is extended to Lists.