Marketing Cloud - Cross Cloud Architecture - Showing Email in Core - July 2023.pdf

Options for showing
the actual email
inside Core Platform
Marketing Cloud - Cross Cloud Architecture
Kenneth Wagner, RVP - Marketing Cloud Services
Salesforce Services - Northern Europe
Updated 20th of July, 2023

Forward-Looking Statements
Statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize
or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by
the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any
projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans
of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and
customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our
service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth,
interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible
mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our
employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com
products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of
salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most
recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information
section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be
delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available.
Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Introduction
In this presentation we will be presenting various
design patterns, to showcase how a company can
show the actual email that a recipient has received.
No one solution in this deck is perfect, and most
companies will often need to resort to a
hybrid-model in order to solve for immediacy and for
historical purposes.

Business Priorities
Solution Considerations
● The users in Sales & Service Cloud have a desire to see all the (relevant)
communications that marketing has sent to a Lead or Contact
● The users must be able to see them the minute a message is delivered, in order to
ensure that if a customer calls, they share the same view
● Some companies might have a need to only show certain tracking results in Sales &
Service Cloud, i.e. Brand A might not see the tracking from Brand B and vice versa

Business Priorities
Key Technical Use Cases Covered
● Display the actual message received in the context of the User
● Displaying omni-channel tracking results sent via Marketing CLoud inside Sales &
Service Cloud
● Storage consumption in Sales & Service Cloud
● The ability to only show a subset of tracking results based on the user viewing them

Assumptions
Technical assumptions informing the design
● SubscriberKey in Marketing Cloud is equal to Salesforce Lead or Contact Id
● The design is built around a single business unit, in order to keep the model and ﬂows
clear. The impact of adding more BU’s should be considered if needed.
● SubscriberKey is assumed to be constant in this design. If SubscriberKey can change,
you need to ensure you account for this in your design, which depends on which
model you choose.
● Implementation team would have all the needed expertise for the desired solution as
part of their team
● Customer has appropriate salesforce editions, storage available and enough
licenses/limits (i.e. enough API calls) to support the desired solution

Limitations to this presentation
Some scenario / requirements are not covered
Tracking results in this presentation is interpreted as a record noting you where sent a message and
your interactions with that message (e.g. opened or clicked links) and as such the following is not
covered by the following slides:
● The need to see which speciﬁc link was clicked, will also require additional modiﬁcations to the
design presented in the following slides
● The designs does not address the need to display web and app behaviour, nor the
advertisements that a user is exposed to
With the introduction of Data Cloud, new “Engagement Data” components are made possible, and
while it doesn’t show the actual email, for a business usage perspective, the design should be
considered (e.g. store data in DC incl. links to see email from external storage location etc.- but that is
outside the scope of this presentation)

Modifications and changes since initial deck
● Removed Record Visibility as this is assumed solvable across all scenarios, as they all involve enriching the
“email records” or “tracking records” with additional data (e.g. country, brand, business line etc.) which can
be used in the Core Platform’s Security model to control visibility
● Updated email metrics part as the .eml file would still contain the tracking pixel, hence in order to prevent
influence of open rates, you need to remove the tracking pixel from the html / eml files before making them
viewable to service agents. Depending on solution, avoiding the impact to clicks means instructing your
users to not click links in the emails (or have a script that removes the a href part of the link in the html)
● Added an indicator on Send Methods, as the Send Log isn’t supported by all send methods, whereas Email
Archiving is controlled by Send Classification instead resulting in a matrix of options to control which emails
you archive
● Removed omni-channel support, as this is a custom-development and capability across all the solution
patterns. Replaced it with “Email Visibility” and linked this to having the html/eml files, as this is least
impactful. HTTPGet on VAWP links will impact metrics and hence for options relying on those, they’ve been
marked “Red” in complying with email visibility.
Credit to Hugues Rousselot for a thorough review of the original deck

Design Options
Cross-Cloud Architecture for Showing Emails
(messages)

Available Options for Displaying the Email
Option 1: Supplementing
the Standard Connector
Using the standard marketing cloud
connector and supplementing the
capabilities with a load to IERs
Option 2: Send Log with
VAWP URL
Store VAWP Link in a Send Log Data
Extension using AMPscript and
showcase it in Core either by loading
data or having an external object
Option 3: Send Log with a
Lightning Component
Like Option 2 or 3, you store the info in a
Send Log DE, but instead of exporting or
loading, a Data Extension is referenced
by a button click for latest email sends
Option 4: Email Archiving
with file processing
All emails sent will generate an .eml file
which can be processed and exposed on
core platform to showcase actual email
(ideally not stored on platform)
Unscalable Architecture:
Send Log with Full HTML
Store Full HTML in a Send Log Data
Extension using AMPscript and
Pros:
- No License Impact in MC or
Sales/Service Cloud
- It may be possible to restrict
access based on user
Cons:
- Significant impacts on storage
usage within Sales & Service
Cloud
- Does not support omni-channel
tracking
- Impact on MC Account
Performance
- Potential Impact on Email
Metrics
- Is not immediately available
- Does not support all sending
methods in Marketing Cloud
Pros:
- Available Immediately
Cons:
- Potential impact on
Sales/Service Cloud Licenses
(SF Connect)
Performance
Metrics
- Potential Impact on Storage
inside Sales or Service Cloud
Pros:
- No impact on storage usage in
Sales & Service Cloud
- Maybe possible to restrict
access, but increases
complexity of API call logic
- No Impact on Licenses
Cons:
Performance
Metrics
- Will not work if there are too
many users trying to retrieve
data at the same time due to
concurrent api call limit
Pros:
- Allows for visualizing the actual
email in the platform
- Possible to use without
impacting open and click rate
- Supports all sending methods
in Marketing Cloud (and you
have a degree of control)
Cons:
- Impact on Marketing Cloud
Licenses (Email Archiving)
(SF Connect)
Performance (mainly OMM)
- Potential Impact on storage
consumption inside Sales &
Service Cloud
Pros:
- Allows for visualizing the actual
email in the platform
- Supports all sending methods
in Marketing Cloud (and you
have a degree of control)
Cons:
(SF Connect)
Metrics
- Severe impact on MC Account
Performance
- Potential Impact on Storage
inside Sales or Service Cloud
Solution should be subject to POC to
determine if it scales appropriately.
This should be avoided at all costs
and is not recommended in any way.

Option 1:
Supplementing the Standard Marketing Cloud Connector
● Risk of impacting the Email
Metrics (Open, Clicks)
● Design will have an impact on
MC Account Performance
● It may be possible to restrict
● Impact on Marketing Cloud
licenses (Email Archiving)
● Impact on impact Sales/Service
Cloud licenses (SF Connect)
● Impact on Storage Consumption
on the Core Platform
● Results immediately available
● Possibile to visualize the email
directly in the platform
● Supports all email sending
methods within Marketing Cloud
Solution v Requirements
NB: If the client needs to send 2 emails to same subscriber as part of same email blast, this design might not work
(think 1 person, 2 cars, 1 email per car). The reason is that each send will not have their own unique Merge Id on our
backed - depends on how the email is delivered etc. Suggest to investigate this deeply before implementing.

Option 2:
Using VAWP Link to Access the sent Email

Option 3:
Lightning Component to Fetch Tracking Data
WARNING:
This solution should be subject to POC to determine
if it scales appropriately. If Tracking DE has a lot of
records, this option seems unlikely to scale

Option 3:
Lightning Component Limitations
# Limitation Commentary Doc
1 Continuations are not supported in
Lightning
Update: Continuations now supported
with Summer ‘19
In order to use the Lightning Component proposed on this slide, the developer would still be
required to develop (1.) a Visualforce page and (2.) an Apex Class where: The Lightning
Component has a Visualforce page embedded which calls for data from an Apex Controller using
JavaScript Remoting
Link
2 The number of concurrent apex callouts
to external systems from a core
Salesforce org is limited to 5
A single Production Salesforce org can only have 5 active callouts at a time. So if you have 10
sales people navigate to 10 different Contact records and click the "view tracking data" button at
the same time, that will result in more than 5 concurrent callouts and some of them will fail.
Link
3 Response time of a single API callout
cannot exceed 5 seconds
Any single callout from a core Salesforce org cannot take more than 5 seconds. Link
4 No caching of data in the Lightning
Component
Some developers might be attempted to “Cache” frequently requested data, but as it is tracking
data and hopefully not retrieved very often, it is important to observe that caching shouldn’t be
used as this can significantly impact performance across the solution
*The following table outlines the potential limitations and are ranked in priority order where number 1 is most likely to be a show-stopper

Option 4:
Email Archiving to display actual email sent

Unscalable and Non-Recommended Architecture:
Storing Message HTML at Sent Time
Solution is considered Bad Practice and is not
recommended due to MC Account performance.
This design is added only to
showcase it’s been
considered but should not be
implemented in any way

Recap:
How does it look across the solutions?
Option 1:
Supplementing
Standard
Connector
Option 2:
Using VAWP
Link to access
the email
Option 5:
Use Lightning
Component to
access data
Option 4:
Using Email
Archiving to
store .eml files
Option 3:
Storing full
HTML at send
time
Risk of impacting the Email Metrics (Open, Clicks)
Design will have an impact on Account Performance
It may be possible to restrict access based on user
Impact on Marketing Cloud licenses (Email Archiving)
Impact on impact Sales/Service Cloud licenses (SF
Connect)
Impact on Core Platform Storage Consumption
Results immediately available
Possibile to visualize the email directly in the platform
Supports all email sending methods within Marketing
Cloud

What is the right recommendation?
The honest answer, no single solution can be recommended as they all have drawbacks that will
impact daily operations - either (metrics) or processing speeds.
The recommendation is therefore to carefully gather the business requirements and be very
explicit in asking about the following topics:
● Velocity - how quickly must the email be available?
● History - how many of the past sends should be viewable?
● Totality - should it be all emails sent that is counted, including any transactional email etc.?
● Visibility - are all users allowed to see all the emails sent? if yes, should they see it all?
Some options are shown on the next slides

Hybrid Solution - All Channels

Hybrid Solution - Email Only

Salesforce comments to the Hybrid Solution
Combining what is essentially Option 2 and 4, yields a design that Salesforce
has consistently seen as the most recommended solution.
It uses VAWP with send-time-logged attributes to provide a recency view for
service agents/use-cases paired with email archiving extracts that would then
be pushed off platform to an external/3rd party system meant to host, render,
etc. the archived emails.
The solution has data retention applied to the send log, so that records
disappears ideally after the VAWP link expires or the email has been archived.
Solution still marginally impact opens / clicks when agents click the VAWP
links, and these cannot be identified - but it is a small percentage and solution
is the best Salesforce has observed from the field.

Hybrid Solution - All Channels writing directly to Core
CreateSingleSalesforceObject is a heavy
procedure so most likely doesn’t scale well

Hybrid + Core - interesting, but why?
If you examine the hybrid solution, there is an option to write directly to the core platform at
send time. This will make the VAWP link immediately accessible to agents, and by implementing
i.e. a batch apex job to delete records, you can easily add data retention.
At the expense of some storage consumption (consider it temporary storage), it might be easier
than having a lightning component calling MC, as each Business Unit can directly call the core org
it’s connected to and create the necessary records.
However, the variant comes with a bit but… you should consider if the solution scales to
support the peak email volume like Black Friday (i.e. will 5-50+ million emails delivered
in one blast, result in same amount of API calls to core etc.)
If you want to go this way, it is recommended to apply for a high-risk
architecture process to get final design and expected throughput reviewed
CreateSingleSalesforceObject is a heavy
procedure so most likely doesn’t scale well

Marketing Cloud - Cross Cloud Architecture - Showing Email in Core - July 2023.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to Marketing Cloud - Cross Cloud Architecture - Showing Email in Core - July 2023.pdf

Similar to Marketing Cloud - Cross Cloud Architecture - Showing Email in Core - July 2023.pdf (20)

Recently uploaded

Recently uploaded (20)

Marketing Cloud - Cross Cloud Architecture - Showing Email in Core - July 2023.pdf