Have a Bad Field-ing

Apparently what I really have is a bad pun problem (see – the title of this post). But what I also have is a dislike for some of the field types in Salesforce. checks

There is one field type that I hate above all other. And secretly, I think the more disdain I have for the field, the more requests I get from people to use it. What field is it? The checkbox. Now, I should clarify because the idea of a binary data point is actually a great one, and I am in full support of it. But the problem with the checkbox is the assumption of data. Too often people want to use checkboxes in situation where you shouldn’t because of the implications of an unchecked box.

Let me give some examples. A No Longer At Company checkbox on a contact is a great use of a checkbox. By default, when created a contact on an account, you assume they are an employee of that company, so the unchecked state makes sense. It is only when a contact leaves the organization that you would check this box and remove them from communications or counts of contacts.

In contrast, a Decision Maker checkbox is a terrible idea. You might be thinking “But wait, that’s a piece of data I really want to know!,” and I agree with you. But here’s the problem – how do you know when the answer is no? Image that your outside sales rep talked to the contact & that contact let them know they aren’t the decision maker, but they will be involved in the sales process. That’s a key bit of information, but if all you have is a checkbox, there’s no where to put it.

I propose to you, an alternative solution: the yes-no picklist. In situations where I don’t want to imply a value, I use a simple picklist with only two potential choices: yes and no. You might be thinking that sounds like the exact same thing, but more work to create, but you’d be wrong. Because what the yes-no picklist also offers is a null value. You would create this field with a default value of blank. It eliminates the assumption of no (or unchecked) and provides you only with values that have been entered.

What’s your take on checkboxes? Are you a heavy user, or do you avoid them as much as possible? Have you found a different way to work around the limitations of binary data?


7 Responses to “Have a Bad Field-ing”

  1. I agree, although Checkboxes are nowhere near as #Gawdawful as a Multi-Picklist field. If John Wilkes Booth and Lizzie Borden had a child it would be a Multi-Picklist field.

  2. I absolutely agree! I recently added a section of fields to one of our custom objects and was fortunate enough to convince the group that a Yes/No picklist was a better idea. Great minds think alike. 🙂

  3. @Becka Great Post! So many times I see the checkbox fields that are out of date (or not used because someone doesn’t understand their purpose, and therefore a similar, yet essentially duplicate, field is requested to account for the slight variations…..Gotta love when a contact is marked as “active” as well as “no longer employed” because one unit wanted to it worded in a different way).

    There is a major problem too with orgs that create VRs around these checkboxes, and don’t account for the time that has passed since they were last evaluated (example: if you have a “decision maker” checkbox that goes un-checked on a contact record, who’s to say the last time that was actually verified? Or if someone is no longer the decision maker, ensuring that a new contact on the account is now marked as such? Leaves users not adopting the field since the data eventually becomes unreliable). – But this is not to say I haven’t been guilty of this, there just weren’t as many great blogs out there for new admins when I started, so I had to learn the hard way (with #eggOnMyFace).

    Agree with @SteveMo; Multi-select picklists are always used in an org in lieu of using a junction object to build a relationship. The result ends up being “it was a great idea…at-first”; until eventually the business units learn that the reporting is a mess, and that no one is keeping it up to date. @Becka: really looking forward to the post on these, I know so many admins that have yet to learn when a multi-select picklist is, or is not, the best solution (since there are [a few] times they have a purpose).

  4. Couldn’t agree more.

    The assumption that “null” is a value of No/Off/False is a common and persistent pain point. I suppose this misnomer stems more from grasp of mathematics than UI concepts.

  5. Completely agree, with a yes/no picklist, we can actually tell when a field hasn’t been updated, or is actually no/false. I do like checkboxes, however, for the ability to summarize them in reports.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: