Skip to content
SteveTechArcSteveTechArc Courses

Study guide

Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Image generated with AI

Study guide for chapter 4 of the Data Architect course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

The exam guide says it doesn’t test non-Salesforce database concepts, and most of this chapter is about the enterprise around Salesforce. So, like chapter 1, this checklist says which objectives each point supports. But don’t skip it: a lot of exam scenarios start with an ERP, a warehouse or a second org, and the answer depends on who owns the data.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

Who owns the data (supports SDM-2, SDM-3 and the Master Data chapter)

The kinds of data and their workloads (supports DM-1, LDV-1 and MDM-4)

  • I can tell master, reference, transactional, metadata, analytical and unstructured data apart, and what each means for where it lives. (Start With the Kind, Not the Object)
  • I know reference data is small but is where integration assumptions hide (Delivered, Complete, D). (Reference Data)
  • I can tell operational (OLTP), analytical (OLAP) and streaming workloads apart: the org runs the business, warehouses and lakes analyze it. (The Kind Is Only Half the Question)
  • I know synchronous (wait at the door), asynchronous (carry on, deal with it when it comes back) and batch (hourly, every few hours, daily), when batch is enough, and that real time has a cost. (How Fast Does It Need to Move?)
  • I ask the four questions of every data set: who owns it, how fast it changes, how big it gets, and its lifecycle. (The Four Questions Behind the Categories)

The systems around Salesforce (supports SDM-3, LDV-3 and the integration chapters)

Orgs and hosting (supports SDM-4)

  • I start with one org and look for a real boundary (residency, regulation, legal separation, a different operating model, an acquisition) before adding another. (Start With One Org, Look for Real Boundaries)
  • I know what multiple orgs cost: global reporting, master data, integration, identity and deployments, each multiplied. (Walk the Arrows Again)
  • I know Hyperforce gives a choice of the region where an org’s data resides (not the cloud provider), but doesn’t promise every service stays there; and that GDPR doesn’t by itself require a separate org: it sets rules for personal data leaving the EU, and a company may choose a European org to meet them. (Hosting Is Part of the Drawing, When Europe Gets Its Own Org)

Drawing and reading a landscape (supports every scenario)

  • I can draw a landscape: people left, Salesforce middle with its communities touching below, identity above, integration and back office right, Data 360 below the integration layer, channels below, data in and out bottom right. (Steve’s Landscape Layout)
  • On a landscape, an arrow starts at the system that opens the connection and its label says what moves and which way; on a data-flow diagram, arrows follow the data. Two flows are two arrows. (Now Draw the Arrows)
  • For every arrow I know what the client handles and what the server defines: where, authentication, protocol and contract, payload, timing, trace, errors. A Named Credential and its External Credential when Salesforce calls out; an External Client App and an API-only integration user when something calls Salesforce. (Every Arrow Needs a Mechanism)
  • I count before I draw the arrows: the volume goes in the inventory and drives the mechanism, and can even change which way the arrow points. (Put the Zeros in the Inventory)
  • I draw a swim lane only when a process has more than one or two back-and-forth exchanges. (Arrows on the Landscape, Conversations in a Swim Lane)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Draw the landscape before you design the org. Start from a blank canvas.
  • Pull the camera back. Salesforce is one system among many.
  • The new wave rarely makes the old one disappear. Architect the enterprise that exists, not the brochure.
  • Read the landscape as responsibilities, not logos.
  • One-way arrows make me nervous. What does this flow depend on, and what comes back?
  • Every arrow needs a mechanism. “Fire and forget” isn’t an answer.
  • Arrows on the landscape, conversations in a swim lane.
  • Count before you draw the arrows. The zeros go in the inventory, and they choose the mechanism.
  • Draw the current state before you fix it: the spreadsheet, the SFTP drop, the system “we’re retiring.”
  • Mark a current state honestly: red for a bad process, dashed for by hand, red dots for what’s missing. Every red line is a requirement waiting to be written.
  • Two flows, two arrows. A double-headed arrow is only for a connector.
  • Don’t play lawyer. Ask which specific requirement you’re satisfying, and translate it with the people who own it.
  • Separate isn’t the same as simple.

Words to Know

Section titled “Words to Know”
TermIn one line
System landscapeThe systems around Salesforce, the people who use them, and the important flows between them
System of recordWhere the authoritative version of a kind of data is kept
System of engagementWhere people do the work
System of referenceWhere a system looks up information it needs but doesn’t own
System of insightWhere data comes together to measure, analyze and predict
ERPThe back-office system for finance, products, inventory, purchasing and fulfillment
Master dataThe durable things a business runs around: customers, products, locations
Reference dataThe shared vocabulary that classifies other data: codes, statuses, categories
Transactional dataRecords of what happened: orders, deliveries, payments, cases
Analytical dataData derived from other data to measure and compare
Unstructured dataDocuments, images, audio, video, transcripts
Data warehouse / lake / lakehouseStructured analytical store / raw store at scale / a mix of the two
ESB / iPaaSAn integration layer that mediates between systems
OLTP / OLAPOperational work on a few records at a time / analysis across many
Near-coreManaged on core, hosted off core: Data 360
Named Credential / External CredentialWhere Salesforce keeps an outbound endpoint / its authentication
External Client AppHow an outside system is authorized to call Salesforce
Current stateThe landscape as it is today, before the design; marked with what’s wrong
Identity provider (IdP)The system that authenticates users and establishes the identity Salesforce trusts
Synchronous / asynchronous / batchWaiting for the answer / carrying on and handling it when it comes / moving data as a group on a schedule
HyperforceSalesforce on public-cloud infrastructure, with a choice of region
Zero copyQuerying data where it lives, without copying it

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. Salespeople work accounts in Salesforce, but the ERP issues the official customer number once they buy. Salesforce sends orders to the ERP. What do you need to design?

Who owns the customer at each stage; the ERP’s number as an External ID on the Account; which fields Salesforce may change; how fast ERP changes arrive; and what comes back after an order is sent (accepted, rejected, shipped, invoiced). Reread The Landscape Changes the Data Model.

2. Leadership wants five years of on-time performance by region, joined to finance. Build it as Salesforce reports?

Probably not. It’s an analytical workload across several stores, so it belongs where the data comes together: the warehouse, with CRM Analytics or Tableau on top. Where analytics lives follows where the data lives. Reread Analytics Lives Where the Data Lives.

3. A company operates in 30 countries and asks for one org per country. What do you ask?

What requirement comes with each country: storage, processing, cross-border transfer, contracts, a different host. Without a real boundary, start with one org, because every extra org multiplies reporting, master data, integration, identity and deployments. Reread Geography Isn’t Automatically an Org Strategy.

4. Trucks send 200,000 GPS readings a day. Should Salesforce store them all?

Probably not. It’s streaming data: the dispatcher needs the current position, while history and trends belong on a platform built for that volume. Count the zeros (over 70 million a year) and separate “where is it now?” from “what happened last quarter?”. Reread The Kind Is Only Half the Question.

5. Crews work their stops in Salesforce, but the routes are built in a legacy dispatch tool, and nothing connects the two. How do you draw today?

As it is, marked as a current state: the routes rekeyed into Salesforce and the completed stops rekeyed back, dashed because people do it and red because it’s wrong. Don’t draw the integration you wish existed; every red line becomes a requirement for the design. Reread Mark What’s Wrong and RouteDesk Is Still There.

6. Someone says European privacy law requires a separate org. How do you respond?

Neither accept it blindly nor overrule it. GDPR doesn’t by itself require a separate org; it sets rules for personal data, including transfers out of the EU. Ask which specific requirement it satisfies (storage, processing, transfer, support access, a contract, policy), then work with privacy, legal and security to turn that into architecture. Reread Don’t Play Lawyer and When Europe Gets Its Own Org.

7. Salesforce sends orders to the ERP's API. Which side handles retries, and where does Salesforce keep the secret?

Salesforce is the client: it opens the connection, sees the whole round trip and is the only side that can retry. A Named Credential holds the endpoint, and its External Credential the authentication. The ERP, the server, defines the contract and validates what comes in. Reread Every Arrow Needs a Mechanism.

8. An integration sends a couple of records a minute today, and the business expects tens of thousands an hour next year. Does the arrow change?

Possibly its mechanism and even its direction. A few records a minute can be a callout from Salesforce; far more may mean publishing events that the other system subscribes to, so the arrow starts at the other end; millions overnight is a batch. Know the counts before you choose. Reread Put the Zeros in the Inventory.

Explore

Section titled “Explore”