Allow a blank default for Yes/No fields
D
David Mahaffey
Most field types can be set with a blank default, but not Yes/No fields. In my use case, I'd like to force users creating a new record to affirmatively indicate the starting state of a Yes/No field. Marking the field as required doesn't achieve this because the field's default state is already either Yes or No, which means that validation doesn't flag the field as missing data when users try to save.
Example:
I have a Yes/No field called "Is a Contract Required?" This is a question where the answer is a binary, so I didn't opt to use a Single Select field. I also like the heightened visibility of the Yes/No field for grid and other views compared to the way Single Selects display. The field defaults to No because most of my records do not require a contract and, more importantly, because I have no "User Input Required" option for the default that would leave the field blank until I enter Yes or No when creating or updating a record.
I'm entering data for a new record, and since the default for this field is No it becomes habit to ignore the Contract Required field, which is usually set to the correct option. Then I encounter an item that does need a contract. I should mark the Contract Required field as Yes, but because I've been effectively skipping the field for some time, I reflexively do so again. Now my record says it does not require a contract when it in fact does.
I have automations keying off this field when it is set to Yes, and for this record, those automations do not run. A contract record is not created, assignments don't get made, notifications don't go out. We risk inadvertently proceeding without a contract for the work associated with this record.
Y
YES Integrations
You could use a single select field for this and create three options: Yes, No and Not Set as default. The current yes/no field is equivalent to a boolean true/false field and having a third possible value in it would mess up all sorts of third party integrations.
D
David Mahaffey
YES Integrations Agreed that the current implementation is equivalent to a boolean field. I suppose what I'm asking for is the option of making it a nullable boolean field (particularly while a draft record is pending its initial save), which is a concept in, say, Java or C# and in database systems like SQL.
Like you, I also suggested in a comment that a Single Select field is a workaround. We lose the visual signal that the Yes/No field offers if we use a Single Select instead, and we lose the simpler filter/condition logic options available with the Yes/No field as well.
Also worth noting that I am not advocating for SAVED records to allow for a null state, which is where integrations would be truly borked and where something like the Single Select workaround would be best practice. I'm saying that a record with a REQUIRED Yes/No field should force the user to make an explicit Yes/No choice in order to save the record. Otherwise it's trivial for the user to sail right past a required field that they are never prompted to consider. Data hygiene goes out the window without effective validation mechanisms, and in that regard the current implementation is weak.
Y
YES Integrations
David Mahaffey thanks for the clarification, I can definitely support requiring the user to enter a value when a yes/no field is required. As an aside I tend to use single select fields wherever possible for user entered values (because they display a bit nicer, have descriptions for choices and null/default values are better supported). If I have concerns about losing the easy filtering etc that comes with yes/no fields I set up a formula field to display a yes/no when the single select displays the corresponding value
Jon Darbyshire
Hey David Mahaffey, thanks for your feedback! I have a few more questions for you:
- Can you provide more examples of fields where you would like to see this change implemented?
- Are there any other field types where you would like to see a similar functionality?
- How often do you encounter situations where the default 'No' option leads to incorrect data entry?
D
David Mahaffey
Jon Darbyshire
- We have several. An analogous one to the contracts field is one that indicates whether or not payment is required. Again, most of our records do not require that we send a payment, and when we need to, it's a big deal to miss our payment deadline.
We're also using Y/N fields to indicate whether a contact is deceased and whether a manuscript we are publishing is a reprint (rather than a first-run piece).
One more: on contact records we track whether the person's byline should default to a pseudonym. Some authors publish exclusively under a pseudonym, and they should have the "Default to Pseudonym" field set to Yes. Others publish under pseudonyms occasionally and under their real name most of the time, so their "Default to Pseudonym" is set to No. We have formulas that refer to this field in conjunction with some text fields to indicate what each contact's default byline should be.
- I can't think of any other field types where this would be needed, because most fields already work this way. If I don't set a default on a Single Select, and I make it a required field (on the record or on a form), then a user MUST make a selection in order to save a record. As far as I can tell only the Yes/No field's default state pre-empts a user making a selection during record creation.
- It's infrequent. Maybe 5% of the time. But it's the kind of thing where getting it wrong has a disproportionate effect. We could end up publishing work we don't have permission to publish or failing to pay a contributor we agreed to pay. In truth, I am likely to switch these fields to Single Selects to ensure we have the necessary control over them even though, as I said, I prefer the visual language of the Yes/No fields. I may even use a Single Select in conjunction with an automation so we enforce correct capture during data entry but toggle a Yes/No field after the fact. I don't love burning through automations to solve the problem, though.
David