Choosing a Field Type

The field type you pick on day one is one of the most important decisions you'll make when designing an object. It looks like a small choice, but once real records start filling that field, switching to a different type means moving data by hand or running a script against the API. It's worth pausing for a minute to plan.

TLDR

• Once a field has data, you can't change its type. You'd have to add a new field and migrate data manually or by script.
• Before adding a Yes/No, ask: "could there ever be a third option here?" If yes, use a Dropdown with two options instead.
• When in doubt between two field types, pick the more flexible one. Dropdown over Yes/No, Multi-Dropdown over Dropdown if multiple answers could ever apply, Dropdown over free Text whenever the values come from a known list.
• Talk to the people who'll read reports off the field before you build it. They usually know about options the original requester didn't mention.

A real story: the "Wisetack" field

A team came to us asking for a Yes/No field called Wisetack on their Jobs object so they could mark whether a customer used Wisetack financing. We added it. People started using it.

A week later, someone else on the team had a better idea. Customers don't only use Wisetack; they also use HELOCs, 401K loans, and other options outside of credit cards. What the team really wanted was a Dropdown called Financing with options like Wisetack, HELOC, 401K, and Other so they could track every way customers were paying for jobs.

Now the team had a problem:

• The Wisetack Yes/No field already had data in it.
• Switching to a Financing dropdown meant every record marked Yes for Wisetack had to be re-entered with Wisetack selected on the new field.
• That's either a manual sweep through every record, or a script that uses the Engine Awesome API to read the old field and write the new one.

Either way, it's painful. And every minute the migration takes is a minute the team isn't doing the work they actually do.

Why changing field types is so expensive

Each field stores its data under a unique slug, in the format that field type expects. A Yes/No field stores true or false. A Dropdown stores the option name as a string. Even if both fields live on the same object, Engine Awesome treats them as completely separate storage. There is no automatic conversion between them, because there's no safe way to guess what the new field should hold.

That means once data is in the old field, you have three options:

1. Live with it. Keep both fields, accept the messiness, and move on.
2. Re-enter the data. Open every record, copy the old value, set the new value, save.
3. Write a script. Use the Engine Awesome API to read the old field on every record and write to the new field, then hide or remove the old field.

Option 1 leaves clutter. Option 2 burns hours. Option 3 takes a developer.

Rules of thumb before you pick a field type

1. Ask "could there ever be a third option?"

This is the question that would have saved the Wisetack team. Yes/No is only the right type when the answer is truly binary forever. The moment a third option is plausible, like a different financing source, a Yes/No field becomes a Dropdown waiting to happen.

If you can imagine even one realistic future option beyond Yes and No, start with a Dropdown. You can always seed it with two options today and add more later.

2. Pick the most flexible type that still fits

When in doubt between two types, pick the one that covers more cases without losing meaning:

• Yes/No vs. Dropdown: pick Dropdown if there's any chance of a third state.
• Radio vs. Dropdown: both are single-select. Pick Dropdown when you have 5+ options or expect the list to grow.
• Dropdown vs. Multi-Dropdown: pick Multi-Dropdown if a record could ever match more than one option at the same time.
• Text vs. Dropdown: pick Dropdown for any value that comes from a known finite list. Free-text fields lead to inconsistent values like "Wisetack", "wisetack", and "Wise tack" sitting in the same column.

3. Talk to the people who will read the data

Before you add a field, ask the team that's going to read reports off it: "what other versions of this answer might come up?" The Wisetack request looked binary until someone outside the original conversation pointed out HELOCs and 401Ks. A two-minute hallway check often reveals the third, fourth, and fifth option.

4. Look at the existing data first

If you're adding a field to an object that already has records, scan a sample of those records. Free-text notes and comment fields often hint at categories you didn't know existed. The list of values people have already been writing in by hand becomes your dropdown options.

5. Treat field design like a small commitment, not a quick decision

Adding a field takes ten seconds. Replacing one once it has data takes hours. The asymmetry is what makes this worth thinking through, even when the choice feels obvious.

When changing the field type is unavoidable

Sometimes you'll discover the wrong choice after data is already in the field. When that happens:

1. Add the new field with the right type alongside the old one. Don't delete the old one yet.
2. Migrate the data. Either by hand for small datasets, or with a script that uses the Engine Awesome API for anything larger.
3. Verify every record has the new value populated correctly.
4. Hide the old field from your layouts so users stop writing to it.
5. Once you're confident the new field is correct everywhere, you can remove the old field.

The short version

Yes/No is a trap when the question is "is this one specific thing true?", because that question almost always grows into "which of these things is true?" If you're tempted to add a Yes/No field, write down the question it's answering and ask whether a Dropdown with two options would do the same job today. If yes, use the Dropdown. Future-you will thank you.