Feature Request Summary: 

Currently, there are four unique values a checkbox can return in Explore when it is unchecked. A checkbox should *never* have more than 2 possible values total, and never more than a single value for unchecked.  This is not how boolean values work. 

Description/Use Cases: 

I have a checkbox. I can see instances where the checkbox was changed from “no” to “no” in tickets. How? Because checkboxes are broken at a base level and defy all logic you’d expect from a boolean field. I’m told that can happen when a checkbox moves from unchecked to unchecked but a different value of unchecked, and it’s not a bug with the product, so here I am writing a use case for making checkboxes boolean. 

Business impact of limitation or missing feature:

This problem makes it difficult/impossible to figure out what happened with checkboxes on tickets. An unchecked checkbox can have Explore values of : False (tickets dataset), 0 (updates dataset), “” (Updates dataset), or NULL (Updates dataset). This is madness. It’s impossible to know what unchecked value to use, because there’s no way to know if it’s a “” unchecked box or a “0” unchecked box that the ticket is showing you. A checkbox should not have an unchecked “starting value” of “” or NULL that shows it then gets updated to “0”, which would mean it was still unchecked.


Extra Flavor:
I know what you’ll say first “Well that’s 2 datasets, so it’s not really fair to count False as part of the issue”. You’re right, it’s a bit unfair to lump it in with this, technically speaking. It only shows True and False on the Tickets set, that’s just two values, so what’s the problem?

Well,  I strongly believe that if you are going to display the same data across multiple datasets in the same product tool, that the values you use to show that data, should stay the same. If an unchecked box is “False” in the Tickets dataset, the Updates dataset should return “False” as well. I shouldn’t have to know that in Updates it’s “0” (or NULL, or “”) not False and “1” not True, even if as a technical expert, I understand that they are the same thing under the hood. Furthermore, I wanted to include it because it really is yet another potential value you need to remember if you’re investigating a checkbox issue, and it’s madness to be keeping track of FOUR possible values that all mean “unchecked” when you're trying to build queries around it.