Data 360

💬 In plain words: Data architecture is deciding—on purpose—which system OWNS each record and field (the System of Record), what your standard data dictionary looks like (the Canonical Model), how copies stay in sync, and who is allowed to change what. Integration just moves data from point A to point B. Data architecture decides why it moves and where the truth lives.

💬 In plain words: Single Org = One house for the whole company. Everyone shares one customer view, one set of processes, one set of data limits, and one big shared codebase. Multi-Org = Separate houses per region or business unit. This provides total freedom and isolation. However, the unified customer view splits, and you end up paying for everything (integration, DevOps , licenses) multiple times. ⚡ 1-Minute Summary Default to a single org strategy. Split only for a hard, named business driver (never just to escape your own slow internal processes). Salesforce Shield adds encrypted storage, activity history, and long-term field history. Encrypt only what is legally required. When inheriting a legacy org: look first, stabilize second, then change. Give yourself 30 days of pure observation before ripping out code. 📌 Example: Forcing Functions for Multi-Org A German subsidiary legally requires strict EU data isolation; a newly acquire...

💬 In plain words: Picking the right Salesforce marketing tool comes down to knowing exactly what you are trying to achieve. Use Marketing Cloud Engagement for massive B2C messaging (email, SMS, push). Use Account Engagement (formerly Pardot) for B2B lead nurturing tied directly to sales. Use Data Cloud (formerly Data 360) as the data foundation that unifies customer records for both. Giving the wrong product answer is the most common mistake architects make on this topic. 📌 Real-Life Example: Three different business requests require three different products: 1. "We need to send two million push notifications for our Black Friday sale." → Use Marketing Cloud . 2. "We need to score our leads over a 6-month buying cycle and hand the hot ones to our sales team." → Use Account Engagement . 3. "We need the system to figure out that these four fragmented records across web, commerce, and service actually belo...

💬 In plain words: Setting up Salesforce Data Cloud (formerly Data 360 / CDP) requires following a strict sequence. You must provision the instance, assign least-privilege permission sets (Admin vs. Aware vs. User), connect your data sources, and only then build your data model. Keep an eye on the meter: data ingestion, processing, and activation all consume credits.

In plain words: In the past, Salesforce Data Cloud relied on scheduled "batches." You waited hours for data to process. Today, Data Cloud can react in near real-time. It can instantly trigger a Salesforce Flow the moment a customer meets a criteria (like abandoning a cart) or when a record changes. The entire Salesforce ecosystem is shifting from scheduled batch processing to event-driven architectures. For data architects and marketers, this shift means you no longer have to cross your fingers and hope your nightly data jobs finish in time for the morning email run. By combining Real-Time Pipelines with Data Cloud-Triggered Flows , you can activate data while the customer is still engaged with your brand.

💬 In plain words: Ask three different departments what "revenue" means, and you will get three different answers. Tableau Semantics is where you define metrics like revenue ONCE. Every report, dashboard, and AI agent across your company then relies on that single, universally agreed-upon definition. 🎬 Real-Life Example: Two Dashboards, Two Revenues Imagine Sales and Finance both have a revenue dashboard. The numbers never match, leading to an argument every single quarter. The Old Way: Both teams assume the other has a data quality issue. They rebuild their own data extracts to prove they are right. The truth? The data is fine. The definitions are different. Sales counts revenue when a deal closes; Finance counts it when the invoice is paid. Both are right, but an AI agent might randomly pick one and confuse the CEO. The New Way (Tableau Semantics): You set out the definition of "revenue" once in the semantic layer...

💬 In plain words: Most of a company's knowledge is not stored in neat database rows. It lives in PDFs, contracts, emails, call recordings, and diagrams. Intelligent Context is how Salesforce Data Cloud makes all of that messy, real-world data usable by an AI agent. 📌 Real-Life Example: A customer asks your AI agent, "Does my warranty cover water damage?" The answer isn't in a standard CRM field. It is buried on page 14 of a massive PDF document. Intelligent Context allows the agent to find that exact paragraph, read it, and answer the customer accurately.

💬 In plain words: Zero-Copy means you do NOT move the data. Your rows stay exactly where they are—in Snowflake, Databricks, Amazon Redshift, or Google BigQuery. Salesforce Data Cloud reads them in place. That means no data pipeline to build, no expensive second copy to store, and no synchronization jobs breaking at 3:00 AM. 🎬 Real-Life Example: 500 Million Rows, Copied Twice Imagine a company with 500 million billing history rows sitting in Snowflake. The Old Way: Data engineers build a complex pipeline to ingest all 500 million rows into Salesforce. The company pays to store the massive dataset twice. They then spend months babysitting the pipeline to ensure both copies stay perfectly in sync. Meanwhile, the data warehouse team views Salesforce as a competitor duplicating their hard work. The Zero-Copy Way: You simply point Salesforce Data Cloud at the existing Snowflake table. The data is queried in place and dynamically joined ...

💬 In plain words: The consent layer in Salesforce consists of the Privacy Data Model combined with the Consent API. Together, they tie privacy permissions directly to the individual. By centralizing how you read and write permissions, "May we email this person?" stops being a guess or a messy custom field check, and becomes a strict, auditable data query that your segmentation and activation engines automatically respect. 📌 Real-Life Example: A customer texts "STOP" and files a GDPR deletion request. Using the Consent API, the system instantly flips their contact-point consent to opted-out. Tonight’s marketing segment automatically excludes them. Meanwhile, the erasure request triggers a deletion flow that purges their unified profile across the system. Consent is treated as structured data, not a sticky note.

💬 In plain words: Data Kits are the official packaging format for Salesforce Data Cloud (formerly Data 360) configurations. They allow you to bundle up your data streams, mappings, and calculated insights so they can be moved from one Salesforce org to another just like standard metadata. Essentially, it brings proper DevOps to Data Cloud so you can treat your architecture like versioned code instead of manually clicking through setup screens. 🎬 Real-Life Example: The Danger of Manual Deployments The Scenario (The Old/Bad Way): A development team spent weeks building 14 data streams, 60 field mappings, and 5 calculated insights in a sandbox. When it was time to push to production, an admin had to open both orgs side-by-side and manually recreate everything from a spreadsheet checklist. The Problem: This took an entire week. Worse, human error crept in, meaning production no longer perfectly matched the sandbox. There was no real audit trail, and th...

💬 In plain words: Once your data is unified in Salesforce Data Cloud, you need tools to use it. The platform provides a built-in toolset: Data Explorer and Profile Explorer let you browse raw and unified data. Calculated Insights compute complex metrics (like lifetime value). Segmentation lets you build targeted audiences with clicks. Finally, Activation pushes those audiences out to ad platforms, Marketing Cloud, or your CRM to drive real-world action. 📌 Real-life Example: Let's say you want to build a "Champions" segment. First, you calculate Customer Lifetime Value (a Calculated Insight ) to identify people who have spent over $1,000. Next, you combine that with engagement data to find who has been active in the last 30 days (a Segment ). You use Profile Explorer to verify that the resulting unified profiles look correct. Finally, you use Activation to push this highly targeted segment to Meta Ads and Marketing Cloud every night. Insigh...

💬 In plain words: In Salesforce Data Cloud, every Data Model Object (DMO) gets assigned a category. Profile tells us who someone is (individuals). Engagement tells us what happened (time-stamped events). Other is for reference data. This category is not just a cosmetic label—it dictates exactly how Identity Resolution and Segmentation use your data. 📌 Example: Individual and Contact Point Email are Profile DMOs—they define who . Website clicks are an Engagement DMO—they define what happened and when . A product catalog is Other. If you mis-categorize engagement data as a profile, the system will break down trying to "unify" click events as if they were people. 🎬 Real-Life Example: The Segment Marketing Could Not Build The Ask: Marketing requested a simple audience segment: "People who browsed the website but did not buy anything in the last seven days." The Failure: The tech team couldn't build it natively...

💬 In plain words: Building a data pipeline in Salesforce Data Cloud takes two distinct steps: Ingestion (bringing raw data in) and Transformation (shaping and cleaning that data). You can perform both of these steps in real-time ( Streaming ) for instant updates, or on a scheduled basis ( Batch ) for massive, historical datasets. Matching the right ingestion method with the right transformation method is the key to a high-performance Data Cloud architecture.

💬 In plain words: Salesforce Data 360 processes data through a three-stage pipeline: Data Source Object (DSO): The raw landing zone auto-created when a stream connects. Data Lake Object (DLO): Stored, structured, and normalized data within the lake. Data Model Object (DMO): The canonical, standardized business object used for segmentation, insights, and activation. Mapping always flows upward: DLO → DMO . Configure your relationship cardinality accurately (for example, one customer to many purchases), or your identity resolution rules will break. ⚡ 1-Minute Summary The Object Progression: Source Data → DSO (raw stream representation) → DLO (normalized storage) → DMO (canonical consumption model). Normalization vs. Denormalization: Normalize early at the DLO layer for data integrity and storage efficiency; denormalize late at the DMO layer for rapid query performance. Downstre...

💬 In plain words: Think of Data Spaces as apartment walls inside a single Salesforce Data 360 building. They let separate brands, regional business units, or departments manage their own customer data, models, segments, and permissions independently—without forcing you to purchase and maintain multiple expensive Salesforce orgs. 📌 Real-World Architecture Example: A multi-brand holding company manages two distinct retail lines (Brand A and Brand B) inside one Salesforce Data 360 instance: Brand A Data Space: Marketers can only view, query, and segment Brand A retail customers. Brand B Data Space: Strictly walled off so Brand B marketers never see or market to Brand A profiles. Outcome: Complete logical isolation of data, metadata, and activation processes on a single platform license.

💬 In plain words: Data Lake: Ingests raw data in any native format quickly and affordably (schema on read). Data Warehouse: Cleans, structures, and indexes curated data for business intelligence and SQL reporting. Data Lakehouse: Combines the massive scale of a data lake with the governance, schema structure, and ACID speed of a data warehouse—the core engine of Salesforce Data 360. Master Data Management (MDM): Resolves duplicate identities across independent systems to create a single, authoritative Unified Individual profile. 📌 Real-World Architecture Analogy: Data Warehouse: The corporate finance data mart—curated star schemas, strict tables, and governed dashboards. Data Lake: The scalable cloud storage bucket (e.g., AWS S3)—storing raw JSON payloads, clickstream logs, and high-frequency IoT feeds. Data Lakehouse: The modern Data 360 architecture—storing raw lake files with warehouse-l...

💬 In plain words: You can set up Salesforce Data 360 in three ways: Inside your existing org: Your CRM records flow straight into Data 360 with zero extra org management. In a dedicated standalone org: Keeps data strictly isolated and manages independent governance limits. In a sandbox: Lets you build, configure, and validate data pipelines before promoting them to production. ⚡ 1-Minute Summary Single-org setup: Attach Data 360 directly to your main production org for simple management and near-instant CRM connectivity. Enterprise multi-org setup: Use a dedicated Data 360 org with Data Spaces and Multi-Org Connectors to enforce regional compliance and neutral governance. DevOps lifecycle: Build and test configurations in a sandbox first, then package and deploy metadata cleanly to production using Data Kits . 📌 Real-World Architecture Examples: Single-Brand Retailer: O...

⚡ 1-Minute Summary The 5-step data lifecycle: Connect, Harmonize, Unify, Analyze/Predict, and Act. Data pipeline path: Raw data lands in a Data Lake Object (DLO) , is staged in a Data Source Object (DSO) , and maps to a canonical Data Model Object (DMO) . Segments and insights read only from DMOs. Zero-Copy architecture: Move the query, not the data. Federate large external datasets from Snowflake, BigQuery, or Databricks instead of copying them.