From 2018 to 2021 I had the privilege of creating a POV on Marketing Cloud and how to properly do cross-cloud architecture, including the various design choices that one could phase. It's been on my radar for a while, to bring these old decks up to speed with a 2023 version, and as I've seen some of these decks come back to me via the ecosystem, this time around I'd take a more proactive approach in sharing it more widely from the beginning. Important to note, that the series I'll be creating is my personal POV and not necessarily a POV of my employer - that said - i do hope you find it useful. The first deck I'm updating is the "Identity Design" part. I created this originally because of a common misunderstanding I was encountering in my various projects - namely how to not import all contacts in the CRM, into marketing cloud - as importing them via Synchronised Data Extensions will automatically create them in the contact framework. There's generally a few approaches to this; Try to control record visibility of the integration user (this requires you to not use a system admin or copy of system admin profile, for the integration user) Implement the boolean (checkbox) approach for the various object(s), essentially setting true/false on whether to sync to marketing cloud Ditching "Sync DEs" for the people objects, and instead importing them directly into Marketing Cloud as Object or Report Imports The 3rd option was one that the people I engaged with, kept being surprised about. Hence documented it, as it's also the approach that allows you to use MC Connect in combination with a Global Identity Provider, in case you don't use Salesforce's Platform Id's as the Database of Record for the SubscriberKey. Find the material below, and keen to get your POV on how you find the material.

1. Identity Design
Marketing Cloud - Cross Cloud Architecture
Kenneth Wagner, RVP - Marketing Cloud Services
Salesforce Services - Northern Europe
Updated 31st of August, 2023

2. The purpose of this deck is to present 3 different design
patterns that allows for the most optimum use of Marketing
Cloud Connect, the native integration between Marketing
Cloud and Salesforce CRM.
It covers:
● Scenario 1 that impacts contact count
● Scenario 2 that doesn’t impact contact count
● Scenario 3 that cater to a global identity provider

3. Salesforce's High Level Identity Landscape

4. Key Considerations for Solution Design
There are four areas that influence and govern our design
Salesforce Data
Events
This will always
use the lead,
contact or person
account Id as the
SubscriberKey
Individual Email
Results
Pushes data using
the SubscriberKey
as the link to
populate the
lookup field
Subscriber
Allowance
Synchronized data
extensions
generally requires
contacts and
leads, which
auto-creates
subscribers
Global Identity
Solution
Does the client
have a global
identity engine
which creates a
global id for
individuals?

5. Scenario 1:
Core Platform as DOR for SubscriberKey
Importing all “People” will impact number of Contacts in Marketing Cloud
Ability to limit the amount
of contacts inside
Marketing Cloud
Supports Salesforce Data
Events inside Journey
Builder
Supports tracking data
pushed to Core Platform
via standard functionality
Supports a custom /global
Id as the SubscriberKey in
Marketing Cloud

6. Scenario 2:
Core Platform as DOR for SubscriberKey
Importing all “People” will not impact number of Contacts in Marketing Cloud
Ability to limit the amount
of contacts inside
Marketing Cloud
Supports Salesforce Data
Events inside Journey
Builder
Supports tracking data
pushed to Core Platform
via standard functionality
Supports a custom /global
Id as the SubscriberKey in
Marketing Cloud

7. Scenario 3:
Global Identity Provider
Ability to limit the amount
of contacts inside
Marketing Cloud
Supports Salesforce Data
Events inside Journey
Builder
Supports tracking data
pushed to Core Platform
via standard functionality
Supports a custom /global
Id as the SubscriberKey in
Marketing Cloud

8. Scenario Overview
Describing how the data flows will work
Scenario 1
Core as DoR with impact
Scenario 2
Core as DoR without impact
Scenario 3
Global Identity Provider
Ability to limit the amount of
contacts inside Marketing
Cloud
You can only limit the data through a
boolean on each object, often requiring
core development
Import all data in full or as delta as
required. Filter out desired records using
SQL inside Marketing Cloud
Import all data in full as required. Filter out
desired records using SQL inside
Marketing Cloud
Supports Salesforce Data
Events inside Journey Builder No limitations on the functionality provided No limitations on the functionality provided
SF Data Events will leverage “People Id”
as SubscriberKey. You need to build APEX
code or custom solution for this
Supports tracking data pushed
to Core Platform via standard
functionality
No limitations on the functionality provided No limitations on the functionality provided
Will only push records that has 18 char SF
ID as SubKey. You’ll need to build a
custom tracking extract for this.
Supports a custom /global Id as
the SubscriberKey in Marketing
Cloud
SF Data Events + Synchronized DEs will
auto-create contacts using the appropriate
Record ID
SF Data Events will auto-create contacts
using the appropriate Record ID
Global ID to be stored as a custom field on
the “People” objects, and imported into
SFMC using import definitions
Key consideration to the
solution
Simplifies the data flow (one pattern), is
the quickest in terms of data, has more
standard “flows” and is quicker in the data
import / update process
Separates the “People” import into an
automation, which reduces velocity to max
an hourly cadence and requires
coordination with rest of the data flows
May have separate data flows like scenario
2 + need considerations in relation to near
real-time triggering of journeys

9. Option 1A
Synchronized Data Extensions
Option 1B
Object Import
Option 1C
Report Import
Ability to limit the imported
records inside Marketing Cloud
You can only limit the data through a boolean on each
object, often requiring core development
You can only limit the data based on “Age of Import
Data”
Not possible (but also not needed if we can
maintain easy filters in Core)
Ability to limit the imported
records in Core side
You can only limit the data through a boolean on each
object, often requiring core development
Only based on integration user visibility
Limit records based on easy to configure Report
filters
Adding New Fields Simple to add Re-configure Object Import Re-configure Report Import
Deleting Fields Simple to delete Re-configure Object Import Re-configure Report Import
Contacts automatically counts
towards allowance?
Yes No No
Fields (i.e. Attributes)
Considerations
Good Practice: <25
Limit: 250
Good practice: <50 or as little as needed
Limit: 900 fields (custom + standard)
Good practice: <50 or as little as needed
Limit: 1000 fields (SF report limit)
Data Volume Considerations
Observations from the field:
While high volumes are supported, it’s important to
consider the # of records to sync vs. sync speed
Observations from the field:
Overwrite: Seen +15m records with success
Update: Seen 2m+ records with success
Observations from the field:
Overwrite: Same as object import
Update: N/A as import type
Considerations
Alternate Key Objects (Lead, Contact, User) will sync
with ~500k records pr. hour with ~80 fields
Non-Alt. Key Objects (everything else mostly) will
sync with ~1 to 2m records pr. hour with ~80 fields
>600k records created/modified will trigger a
full-object sync (i.e. Overwrite)
The more fields, the slower import. Testing from 25
to 50 to 100 fields, each step doubled import time
Be cautious in selecting Aged data (i.e. update), as
this will influence the import speed
Custom Lookup Fields will come with 15 char
Record ID’s, which needs to be accounted for in
your data modelling (e.g. CaseSafeID or other)
The more fields selected, the slower the import will
be. From testing from 25 to 50 to 100 fields, each
bracket doubled the import time
Custom Lookup Fields will come with 15 char
Record ID’s, which needs to be accounted for in
your data modelling (e.g. CaseSafeID or other)
NB: Credit to Ramiro Poli de Langhe for compiling the above overview A pattern here could be Object for daily overwrites and Reports to support importing Delta’s
(if this is required for your desired solution)
What should I choose to bring in Data from CRM?

10. When using Person Accounts in CRM
When Person Accounts are turned it adds a series of fields to the
account object (PersonContactId, PersonEmail etc.) which originate
from the Contact Object but is stored on the Person Account.
THIS ENABLES YOU TO:
● Start and stop the contact object sync, to enable the
synchronization of the account object
● AccountID (which is the primary key for Accounts) will not be
automatically added to the contact framework
● Still use PersonContactID as your SubscriberKey, which will
enable you to work with Individual Email Result records if this is
a desire for the implementation

11. Thank you