The Data Dictionary
Это содержимое пока не доступно на вашем языке.
Before I set anything up in Salesforce, I plan it in a data dictionary. In 2024 I made a video of the one I use: a shared sheet where every object and every field is written down, with what it means, its type, how it relates to the others, and whether it’s built yet. That was for the core platform. Data 360 makes it close to required. In my own words from the Data 360 Diaries: “Best practices with Data Cloud is do your mapping outside of Data Cloud, determine exactly what you need, and only bring in the records you need.”
This page is the method, in one place, for every course that uses it. It’s a theme that runs through all the SteveTechArc courses: whatever you’re designing, plan the data first.
Watch it on video
Section titled “Watch it on video”Here’s the dictionary I use, in a 2024 video: planning a design before anything is set up in Salesforce. Since then, the same idea has grown into what the rest of this page describes: a dictionary that follows the data from its source all the way into Data 360, and grows with every decision.
What a data dictionary is
Section titled “What a data dictionary is”It’s a written plan of your data, made before you build and kept up as you do. For each source and each object, it says:
- What’s in it: every field, what it means in the business’s words, and an example of a real value.
- What type each field is, decided by you, not guessed by a tool.
- What makes a row unique: the key, and the keys that point to other things.
- What’s sensitive: personal data, and anything that needs care.
- Where it goes: the field it lands in, the object it maps to.
- What it’s used for: the segment, the report, the match, the agent. If nobody can fill this in, the field doesn’t come in.
Three habits make it work:
- Design in a shared sheet before you build. The business, the admins and the developers read the same thing.
- Flag what’s designed but not built yet, until it exists in the org and in source control. The sheet always tells you what’s real.
- It’s a communication tool as much as a record. The best moment for a dictionary is the meeting before anything is built, when a wrong type or a missing key is still a cell in a spreadsheet.
One logical type, three platforms
Section titled “One logical type, three platforms”A field has one meaning, but each platform writes it its own way. The dictionary records the logical type once, and the physical type on each platform follows from it.
| Logical type | Salesforce core | Data 360 | In a CSV file |
|---|---|---|---|
| Text | Text (with a length) | Text | a string |
| Long text | Long Text Area | Text | a string |
| Whole number | Number (no decimals) | Number | an integer |
| Decimal | Number (with decimals) | Number | a decimal |
| Money | Currency | Currency | a decimal |
| Percent | Percent | Percent | a decimal |
| Yes or no | Checkbox | Boolean | true/false, or a 1/0 that needs a decision |
| Date | Date | Date_Only | a date, in one format |
| Date and time | Date/Time | Date (a date and time) | a date and time; without a zone, a problem |
| a string | |||
| Phone | Phone | Phone | a string; one format, such as E.164, for matching |
| Link | URL | URL | a string |
| Picklist | Picklist | Text | a string, from a written list of values |
| Lookup | Lookup or master-detail | Text, as a key | the other record’s key |
Data 360’s types from Salesforce Help, Data Types in Data 360 (opens in a new tab) (version 264.0.0, checked 2026-11-14).
Watch the names. In Data 360, the type called Date holds a date and a time; a date alone is Date_Only. And once a lake object exists, a field’s type can’t be changed, so this column is the one to get right first.
The last column is where the surprises are. A flag written 1.00, a time written 2400, a date with no time zone: the file is valid, and the load is quietly wrong. The Data 360 Architect course walks through real ones.
How it’s evolved, and is still evolving
Section titled “How it’s evolved, and is still evolving”2024: a dictionary of objects. The dictionary in my video was, at heart, a dictionary of Salesforce objects. What are the target objects? What fields does each one need, and of what type? How do they relate to each other: the lookups, the master-details, the record types? And what else hangs off them: the validation rules, the flows, the sharing, the reports? Everything in it was going to become an object or a field in one org, so that’s what it described.
Data 360: a dictionary of everything that comes in. In Data 360, we’re not only bringing in things that will become Salesforce objects. We bring in objects from our orgs, yes, but also flat files, normalized files that point to each other, pivoted tables with a column for every value, nested JSON from APIs, and unstructured text and documents. Each arrives in its own shape. So the dictionary had to grow. It now describes each source as it really is, and then the journey: how it comes in, how it’s stored (the stream, the lake object, its category and its keys), how it’s reshaped, and what it finally means in the model. The question has changed from “which fields do we build?” to “how should this be stored, so that it means the right thing everywhere it’s used?”
Now: a dictionary that people and AI both read. For years, keeping a dictionary meant a person cutting and pasting, row by row, from the sheet into the setup screens and back. That’s changing. AI tools can now read a dictionary, check it, and work from it. That’s why my own dictionary moved from a spreadsheet, to CSV files, to YAML files kept in Git: text that a person can read and an AI can read the same way, that shows exactly what changed and when, and that a tool can check before anything is built. From there it keeps growing: one file per dataset and per mapping, generated views, lineage and impact.
So the habit from 2024 is the same: plan the data before you build. What’s changed is how much a dictionary has to cover, and who can work with it.
From a sheet to a model in Git
Section titled “From a sheet to a model in Git”A sheet is the right place to start. As a project grows, the dictionary can grow into a model that people and AI tools work on together, kept in Git beside everything else:
- One file per dataset: a file, a core object, a stream, a lake object, a model object. Its fields, their logical types, the keys, the format, where it comes from and its license, and a sample of real data in its original format.
- One file per mapping: each line in the data’s journey, from a file to a stream, a stream to a lake object, a transform to an enriched layer, a lake object to the model. Field by field, with the joins and what runs it.
- Generated views: a readable page, a printable document, a card per dataset.
- Questions it can answer: Where did this value come from? (lineage, upstream). What breaks if I change this field? (impact, downstream).
That last question is the reason to do it. In Data 360, much of what you create can’t be undone: a field’s type can’t change once its lake object exists, a stream’s category and its event time are fixed once it’s saved, fields can’t be deleted from a lake object, and the names you choose are the names everything downstream uses. Each of those is decided once, on the day the stream is created. The dictionary is where you decide them on purpose, with the whole picture in front of you, and where you find out what depends on what before you make a change you can’t undo. That’s why, in the Data 360 Architect course, it isn’t a one-time exercise: it runs through the whole course.
A live one, growing with the course
Section titled “A live one, growing with the course”SkyData (opens in a new tab), the course’s own data, keeps a data dictionary for every data set it publishes: the real ones (airports, flights) and the synthetic ones (pilots, certifications). In the Data 360 Architect course, you start your own dictionary in chapter 3 and add to it in every chapter after: the door in chapter 4, the category and the lake in chapter 6, the transforms in chapter 7, the model in chapter 8, and so on. SkyData publishes the dictionary as it should look at the end of each chapter, so you can check your work, and at the end of the course it’s a complete, cross-linked map of everything you built.
- The full dictionary (opens in a new tab): everything so far, in one place, rebuilt with every change.
- The chapter editions (opens in a new tab): one per chapter, each a dated snapshot that never changes.
- A blank template to start your own: dictionary-template.csv (opens in a new tab) (a sheet) or dictionary-template.yaml (opens in a new tab) (one file per dataset).
Where the courses use it
Section titled “Where the courses use it”The data dictionary is a theme across the SteveTechArc courses, and this page is its home. Each course links here and adds its own part.
- Data 360 Architect, chapter 3, module 4: A Data Dictionary Before You Map, and an “update your dictionary” step in each later chapter.
- Data Architect, chapter 5, module 3: Know Your Data, with my 2024 video of the dictionary I use for planning.
- Other courses, as they’re built or reviewed: wherever a course designs data (an integration’s data contract, an identity model), it links here and adds its part.
Explore
Section titled “Explore”- Data Architecture: Using a Data Dictionary for Planning Before You Setup in Salesforce, SteveTechArc on YouTube, 2024-01-26 (the video’s notes are on the Data Architect page above).
- SkyData (opens in a new tab): the course’s data, with its data dictionary (opens in a new tab) (checked 2026-11-14).