Aller au contenu
SteveTechArcSteveTechArc Courses

Know It Before It Comes In

Ce contenu n’est pas encore disponible dans votre langue.

Module 1 in the chapter Understanding Your Data Structures, chapter 3 of the Data 360 Architect course. Each module stands on its own. Next: Flat, Normalized or Unstructured

The question this module answers: Why do you have to understand your data before it comes into Data 360, not after?

In the core org, we’re used to fixing things as we go. Wrong field type? Change it. Bad name? Rename it, update the references, move on. Data 360 doesn’t work like that. Because it’s so hard to delete and change things once they’re in, you really need to know your data before you bring it in.

What you can’t change later

Section titled “What you can’t change later”

When a data stream brings data in, it creates a data lake object, and the mapping connects that to the data model objects. From that moment, some decisions are set.

The clearest one is the field type. Salesforce says it plainly: “After a DLO or DMO is created, you can’t change the data type of any fields.” If you got a type wrong, the fix Salesforce gives is to create a new field with the right type. And you can’t simply remove the old one: in Salesforce’s words, “the original field cannot be fully deleted.” Its advice is to add the word “final” to the new field’s name, so nobody downstream picks the wrong one by mistake.

Names work the same way. When you set up a stream, this is your chance to give it that clean name. Make sure you name it properly, because this is where you get one chance. Otherwise you’re going to have to drop it, and if this data lake object already maps to downstream elements, it can be hard to undo.

And when you do drop something, the damage spreads. If you delete a data stream, there could be a dependent data lake object, data transforms, data model objects built on it. It can be kind of unraveling the sweater: pull one thread and everything knitted from it comes apart.

Even Salesforce’s own setup shortcut follows the rule. The standard data lake objects that Simple Start creates (module 5 of chapter 1) have their category, event time, API names and primary key fields fixed. In Salesforce’s words, they’re “no longer editable.” Even the standard setup is decided once.

One field, chosen in a hurry

Section titled “One field, chosen in a hurry”

Here’s how it happens. Remember the pilots file from chapter 1, with each pilot’s years of flying. Someone sets up the stream on a Friday afternoon and takes the defaults. Years flying comes in as text.

Nothing breaks. The stream runs, the data lands, the pilots show up. Then the segment from chapter 1 asks for pilots with ten or more years of flying, and the answers are wrong. As text, “9” comes after “10”, because text is compared character by character, not as a number. Bad modeling doesn’t break loudly; it creates silent, costly issues.

The fix is a second field, years flying as a number, a new mapping, and the old text field disabled but still there. One field chosen in a hurry, and now there are two, forever. Five minutes of planning would have prevented all of it.

Do the thinking outside

Section titled “Do the thinking outside”

So where does the thinking happen? Not in Data 360. Best practice with Data 360 is to do your mapping outside of it: determine exactly what you need, and only bring in the records you need. Data should be shaped before it lands, not fixed afterward.

That means answering a few questions for every source before you build its stream:

  • What have we got? Every feed and file, its structure, and a sample of real data to check it against (module 4).
  • What shape is it? Flat, normalized or unstructured (module 2).
  • What makes each record unique? The key that will carry it through everything downstream (module 3).
  • If it’s a time series, which date never changes? One row per event needs a date that holds still once it’s written (module 4).
  • What does each field mean, and what type is it? Written down, in a dictionary, before you map (module 4).
  • Do we need it at all? Every field you bring in has a cost and a risk (module 5).

None of this is new to a data architect. What’s new is the price of skipping it. In chapter 1 we saw that Data 360 is feed-based: you change data by changing what you feed it. The same is true of its structure, only more so. You can re-feed a wrong value. A wrong field type stays with you.

What an architect decides here

Section titled “What an architect decides here”
  • Which decisions must be settled before the first stream is built: names, field types, keys.
  • Who reviews a new source before it’s connected, and against what.
  • Your naming standards for streams, data lake objects and fields, written down before anyone needs them.

Explore

Section titled “Explore”

All checked 2026-11-14.