Here's the thing you came for: a free Salesforce field types cheat sheet in Excel — one row per type with when to use it, how it behaves in reports, the mistake people make with it, and whether you can change it later. Download it, keep it next to Object Manager, and the rest of this post is the handful of field-type decisions that are cheap to get right at creation and genuinely expensive to unwind later.
Picking a field type feels like the smallest decision on the field-creation screen. It's often the most consequential one, for a reason the create screen never tells you: it's frequently a one-way door. Salesforce lets you change some field types after the fact, but not all of them — and several conversions silently drop your data. So the type you choose isn't just "what shape is this value." It's a decision about how the field reports, whether automation can use it, and how much pain it is to correct once real data is sitting in it.
Picklist vs text — the reporting decision
If a value comes from a known, finite set — stage, tier, region, status — make it a picklist, not a text field. This is the single most common field-type mistake, and it shows up months later in reporting: a picklist groups cleanly into report rows and dashboard segments; free text gives you "California," "CA," "calif.," and "Calfornia" as four separate values that no report can collapse. Text is for genuinely open input (a name, a note). The moment you can enumerate the values, it's a picklist.
The multi-select picklist trap
Multi-select picklists look convenient and are a reporting and integration headache out of proportion to their usefulness. Filtering on them is awkward (you're matching against a semicolon-delimited string), they report poorly, and they're painful to consume over the API. When you're tempted to reach for one, the honest alternative is usually a related child object or a set of checkboxes. Use them knowingly, not by default.
Formula vs a stored field
A formula field is calculated at read time and stores nothing — it's always current, always read-only, and costs no storage, which makes it perfect for derived values (a computed score, a days-since date, a concatenated label). The trade-offs are real, though: formulas have compile-size limits, can't be set by automation, and can't always be used everywhere a stored field can. If a value needs to be edited, or set once and frozen, it's a stored field — not a formula.
Roll-up summary — and the relationship it requires
A roll-up summary (sum, count, min, max of child records) is enormously useful and has one hard prerequisite people hit constantly: it requires a master-detail relationship (or one of a few standard relationships that behave like one). If your objects are joined by a lookup, you cannot add a roll-up summary — you'd reach for a record-triggered flow, an Apex trigger, or a declarative rollup tool instead. Decide how you're going to aggregate before you pick the relationship type, because the relationship is what gates the option.
Lookup vs master-detail
This is a data-model decision wearing a field-type costume. A master-detail child is owned by its parent: it inherits the parent's sharing, is required, is deleted when the parent is (cascade), and unlocks roll-up summaries — but you get at most two per object, and conversions are constrained. A lookup is a looser link: optional, independently owned, no cascade delete by default, and no roll-ups. Pick master-detail when the child genuinely can't exist without the parent and you want rollups; pick lookup for a reference that stands on its own. And know the conversion rules before you commit: master-detail converts to lookup only if no roll-up summaries depend on it, and lookup converts to master-detail only if every child record already has a parent populated.
The question the create screen never asks: can you change it later?
Some conversions are safe (a picklist to a text field keeps your values). Some are restricted or impossible. And some — shortening a text length, changing number precision, moving off a picklist in the wrong direction — truncate or drop data without much ceremony. Auto-number and formula types especially aren't things you casually convert into. The practical rule: treat the field type as a decision you'll live with, because "I'll just change it later" is sometimes true, sometimes a data-loss event, and you don't want to learn which on a field full of real records.
The field type isn't just the shape of a value. It decides how the field reports, whether automation can touch it, and how much data you lose if you ever have to change it.
The honest catch — the type is only half the story
A cheat sheet tells you what each type is for. What it can't tell you is what's already true in your org: which fields are the wrong type for how they're actually used, which multi-select picklist is quietly breaking a report, which formula is doing work a stored field should, or which fields nobody populates at all. That's not a knowledge gap a reference closes — it's a question about your specific metadata and how it's used, and answering it by clicking through Object Manager one field at a time doesn't scale past a small org.
That's the honest boundary. The cheat sheet makes you fluent in the types; seeing where your org used the wrong one is a different job. SchemaForce inventories every field with its type — and, when you turn on usage, how populated each one actually is — so "is this the right type, and does anyone even use it" becomes something you can see across the whole org instead of guess field by field. And because changing a type later means knowing what references the field first, it maps that too. The cheat sheet is yours to keep; what automation removes is the field-by-field squinting.
Start here
Download the cheat sheet, and the next time you create a field, spend the extra thirty seconds on the type — especially the picklist-vs-text and lookup-vs-master-detail calls, which are the ones you'll regret quietly. Then, when you have a minute, look at the fields you already have with the same eye: the type you'd never choose today is worth knowing about before it's load-bearing. (Naming the field well is the companion decision — the Salesforce naming conventions standard covers that half.)
