Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The decision on the table is how you shape ingestion, the data model and identity rules before the first use case goes live. Those choices look technical. They are also commercial, because they set how much data you process, how fast it moves and how much rework each new use case costs. Getting them right at the start is cheaper than optimising them later.
Two data layers sit side by side on one platform
The core Salesforce platform stores records such as accounts, contacts and cases in a relational database that each org shares with other tenants on its instance. That layer is fast for transactions and automation. It was never designed to hold billions of rows of behavioural data.
Data Cloud (Data 360), which Salesforce first presented as Salesforce Genie, adds a lakehouse layer beside it: storage built for very large volumes that keeps some database guarantees, such as reliable transactions. Because the layer sits inside the platform, its data can drive flows, segments and analytics without a separate connector. Whether that second layer is worth adding is a business question before it is an architecture one, and the case for Salesforce Data Cloud starts there.
Ingestion mode sets speed and cost
Data reaches Data Cloud as a stream, in batches or through federation. Streaming from web and mobile tracking, or through integration tools such as MuleSoft, brings events in within seconds to minutes and suits triggers that must fire fast. Batch ingestion from Salesforce clouds and outside systems runs on a schedule and suits most profile and transaction data. Federation leaves data in a warehouse such as Snowflake and queries it where it sits.
Choose per source, and default to the slowest mode each use case tolerates. Streaming everything feels modern, and it consumes more usage than most use cases need. When a warehouse already holds the data, Data Cloud zero copy integration is usually the first option to test.
The data model is where rework hides
Every source lands first as a data lake object, stored as it arrives, and is then mapped to data model objects: the shared structure Salesforce defines for individuals, contact points, orders and engagement. Mapping to standard objects where they fit keeps segments, insights and new Salesforce features working without custom glue. Custom objects are sometimes necessary. Each one is a place where the next use case needs extra work.
Identity resolution sits on top of that model. Its match rules, such as exact email or a fuzzy name combined with an address, decide how many unified profiles you end up with. Every downstream segment and insight inherits that result, so a change to the rules later ripples through everything built on them.
