A lot of us have been here before. We have a use case that requires us to know if a contact has completed a review. The only potential answers listed in the requirements is true/false, or yes/no, or some other similar flavor of dichotomy.
EASY, we think to ourselves. Just gonna slap a checkbox here and call it a day. I mean, why not? It’s either true or not, right? Surely we don’t need to overthink this.
Unfortunately, like me trying to pick which strange anthropomorphic Salesforce character is my favorite, this does require some more thought. A checkbox, in most cases, is not your best option. Let me explain.
First, a checkbox is not a universal data type. Let’s say this data ever needs to come from or leave Salesforce. There is a good chance that your life is now harder when making that integration. Looking at SQL servers, a really common integration endpoint, a checkbox needs to be translated into a BIT data type with 1 for YES and 0 for NO. This doesn’t seem like a big deal, but it’s very easy to start to lose data integrity when data types for the same data have to be changed in an integration.
Next, a checkbox is an inherently limited field. It can not do ANYTHING except tell you if something is true or false. It’s a pretty lazy field. Let’s go back to that use case: just wanting to know if something is true/false, how can we get more information from a different data type? If we were to use a date field or a date/time field for “review completed,” we still get the value of knowing whether or not it’s true/false, but we get more information - we get information about when this actually happened. With a checkbox, this is information that would have been completely lost and unusable.
Lastly, a checkbox assumes that true/false will always be the only option. On the surface, this seems ok. Going back to our example, a contact has either completed their review or not, right? Well, a few weeks later marketing comes back and says that actually want to see who is “in progress” with their reviews.
After you get done dying inside, you now have to unwind all of the previous development work and redo it. If you started with a picklist of yes/no, then all you would have to do is add a third picklist option. This is monumentally easier than going back and doing a data conversion for ALL the previous values into your new picklist. And it gives you the flexibility to continue adding or editing options as requirements change.
This is a great example of when we, as business analysts, developers, or strategists, need to really think beyond just the requirements we are given. If there is a better way to do something, or a way we think we can achieve the same business results with more value delivered, we should be ready to say that. Checkboxes always seem like a really easy solution, especially for business users who are not responsible for thinking about some of these criteria. At the very least, you are probably saving yourself from hours of re-work by doing it right the first time, which is always the smart move.