A Maintainable Salesforce Marketing Cloud Data Model
How to design a Marketing Cloud contact model with clear identity, governed attributes and data extensions that teams can safely evolve.
Max Rozmetov
CRM Systems & Automation Specialist
A Salesforce Marketing Cloud data model should make customer data easier to use and harder to misuse.
When every campaign creates another customer copy, identity fragments, consent drifts and journey logic becomes dependent on undocumented tables.
Maintainability comes from deliberate boundaries: a canonical contact key, owned source attributes, explicit relationships and separate structures for reusable data and temporary campaign work.
Start with identity, not tables
Define what a contact represents and which identifier remains stable across channels and source systems. Email address is usually a destination, not an identity. It can change, be shared or appear on more than one product relationship.
Document how customer, account, policy and contact-point identifiers relate. Every sendable data extension should use the same identity contract unless there is a deliberate, reviewed reason not to.
Separate systems of record from engagement data
Marketing Cloud orchestrates communication. It should not quietly become the authority for product state, consent or customer value when another system owns those facts.
Salesforce Contact Builder data sources identify where attributes originate. Use that provenance to distinguish synchronised source data, calculated engagement features and campaign-specific outputs.
Keep the shared contact model small
Only place broadly reusable, well-governed attributes in the shared model. Adding every available field increases ambiguity, refresh cost and the chance that teams choose a convenient but inappropriate value.
Salesforce recommends limiting shared attributes to those used across multiple journeys and creating separate structures for one-off work. Treat the contact model as a product with consumers, owners and controlled changes.
Design data extensions for a clear job
Give each data extension one responsibility: source mirror, reusable feature set, journey entry, suppression, send log or temporary output. Define its row grain, primary key, retention, refresh method and downstream consumers.
Use external keys consistently in code and APIs. Names are for people and can change. Keys are integration contracts and should remain stable.
- Purpose and owner
- Row grain and primary key
- Source and refresh expectation
- Retention and deletion behaviour
- Known journeys, queries and integrations
Release schema changes like code
A new field or relationship can change segmentation, personalisation and deletion behaviour. Test schema changes against representative records and dependent queries before promotion.
Maintain a dependency register and deprecation process. A data extension should not remain indefinitely because nobody can prove whether it is used.
The standard for release
A maintainable Marketing Cloud model has stable identity, clear provenance and intentionally small shared structures. Every data extension has a defined job and lifecycle.
Begin by documenting the current contact key and the ten attributes most journeys depend on. That exercise usually exposes the highest-risk ambiguity first.
CRM pre-send QA questions
What should the Marketing Cloud Contact Key represent?
It should represent a stable contact identity that does not change with an email address or campaign. Its relationship to customer, account and channel identifiers must be documented.
How many attributes belong in a shared data foundation?
Only attributes that are governed and commonly required across journeys. Salesforce advises keeping shared attributes to a minimum for performance and functional clarity.
What documentation does a data extension need?
Record its purpose, owner, row grain, primary key, source, refresh process, retention policy, external key and known downstream consumers.
Related project
Anveal: pre-send governance for regulated CRM teams
See how I turned this operating problem into a working governance workflow with deterministic checks, model-assisted review and a retained report.
Read the Anveal case study →