Bỏ qua để đến nội dung
SteveTechArcSteveTechArc Courses

Data 360 in One Picture

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

Chapter 1 of Data 360 Architect, Part 1: Bringing Data In. New here? Start with the course.

If you’re going to show somebody a long journey through a forest, sometimes you take them down the happy path all the way in, and then you come back and work the derivatives. That’s how this course starts. Before any one part of Data 360, you get the whole picture: data comes in from many sources, lands, is modeled, unified on the person, analyzed and acted on, and something useful goes back out. Every later chapter is one part of that picture, in the same place on the same diagram.

Data 360 in one picture Data 360 in one picture: Salesforce in a band across the top, everything outside Salesforce in a band across the bottom, and the flow through Data 360 in the middle, left to right. - **Above, Salesforce:** the home org (the org Data 360 lives in), companion orgs (your other Salesforce orgs), B2C Commerce and Marketing Cloud. Data from all four is pulled down into the connectors. - **Below, outside Salesforce:** websites and apps push up through the Ingestion API; cloud storage such as Amazon S3 is pulled through the connectors; lakehouses (Snowflake, Redshift, BigQuery) are federated through the connectors; external systems reach in through the APIs. - **The doors in:** connectors (set up once, they hold the credentials) and the Ingestion API, streaming or bulk. Both stream into the data stream. - **Streams and the lake:** the data stream (the DSO) lands as a data lake object (the DLO). A data transform reads a DLO and writes a new DLO. - **The model:** mapping takes the DLO to the data model object (the DMO), highlighted as the center of the picture. Beside it: a data transform that reads a DMO and writes a new DMO; a calculated insight, calculated from DLOs or DMOs; the new layer (data graphs, semantic layer, search index), which takes its context from the DMO; and the APIs, which query it. - **Working the model:** on change, data actions send data back up to core, to the home org and companion orgs. Identity resolution matches people into one unified individual. Segments are activated up to Marketing Cloud. Data shares go down to the lakehouses with zero copy. {"author": "Steve Simpson", "blueprint": "1.1.1", "builder": "standard 1.57.1", "built": "2026-10-30", "id": "DGM-D360-PA-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE DOORS IN STREAMS AND THE LAKE THE MODEL WORKING THE MODEL SALESFORCE OUTSIDE SALESFORCE THE DOORS IN STREAMS AND THE LAKE THE MODEL WORKING THE MODEL Home org the org Data 360 lives in Companion orgs your other Salesforce orgs B2C Commerce Marketing Cloud Websites and apps and your own systems Cloud storage Amazon S3 and others External systems reach in through the APIs Lakehouses Snowflake, Redshift, BigQuery Connectors set up once, they hold the credentials Ingestion API you push: streaming or bulk Data transform reads a DLO and writes a new DLO Data stream (DSO) the data as the source sends it Data lake object (DLO) the data stored as it came Data transform reads a DMO and writes a new DMO Calculated insight from DLOs or DMOs The new layer data graphs, semantic layer, search index The APIs query, data graph, connect Data model object (DMO) the standard model, or your own Data actions events, webhooks, flows in core Identity resolution one unified individual Segments sets of people to act on Data shares zero copy out pulled pulled pulled pulled pushed pulled federated back to core back to core activate zero copy reach in streams streams lands reshape mapping reshape calculates calculates context query match segment on change share Salesforce above, everything else below. Data comes in on the left, is shaped into the model, and goes back up to Salesforce or down to the lakehouses. HOW TO READ IT the data model: everything on the right works on it © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The course’s master picture. Every chapter fills in part of it.

The positions in this chapter

Section titled “The positions in this chapter”
  • Start with the happy path. One simple path end to end, then the variations.
  • Two doors from the start. Data from your core org, which is key, and data from outside it. Unifying the two is what gives the rest of the flow its purpose.
  • Bring in the data you need to make good decisions, not all your data. Some data never needs to live in core; core only needs a fact or two from it.
  • Always unify on the individual, and do it from the beginning. Don’t add it later.
  • Use Salesforce’s words where Salesforce has one. Nine verbs: Connect, Ingest, Prepare, Model, Unify, Analyze, Activate, plus the course’s Access and Deploy.
  • One production org is the home org. With more than one, choose one, or stand up a governance org and make the others companions.
  • Data 360 is not a system of record. Everything is feed-based; the source system owns every value.
  • Practice somewhere that isn’t production, and don’t leave practice streams running: a Data 360 sandbox uses production’s credits.

The path through this chapter

Section titled “The path through this chapter”

Five modules, each standing on its own.

  1. One Long Flow (coming soon). One pilot, two doors: a pilots file in Amazon S3 and the home org’s contacts come in, map to the Individual, unify on email, form a segment, and a copy field enrichment sends two fields back to core.
  2. Their Verbs and Ours (coming soon). Salesforce’s three ways of describing Data 360, the nine verbs this course uses, why “harmonize” isn’t one of them, and where to look things up in Salesforce Help.
  3. A Different Space (coming soon). Why Data 360 behaves completely differently from the core org, and how to choose its home org: your one production org, or a governance org with companions.
  4. What Data 360 Is, and Isn’t (coming soon). When data belongs in Data 360 (volume, type, processing you don’t want in core), and why it’s feed-based and never the system of record.
  5. Before You Start (coming soon). An org to practice in, what Simple Start sets up for you, a first word on credits, and the data modeling you should already know.

What an architect decides here

Section titled “What an architect decides here”
  • Which data has a reason to live in core, and which only needs to send a fact or two back.
  • Which sources come in, and which fields from each.
  • What makes two records the same person, and how strict that rule should be.
  • Where your team practices, and who watches credit use from the first week.

Explore

Section titled “Explore”

All checked 2026-11-01.

Next: Understanding Your Data Structures