The thing is that booleans should, kinda by definition of what booleans are, only ever have 2 states: TRUE or FALSE (or 1/0).
The fact that booleans in r3 can be null (a third state) is due to the technical underpinnings of how the database system works. It can also sometimes be useful for functions for migrations etc.
But for users, I would strongly suggest to build apps where booleans are by default either TRUE or FALSE - but never null. null is often confusing to users and is also hard to deal with in filters, form states and everywhere else. It is possible to deal with null in booleans - but it´s always more complicated. Even on an attribute level, I would try to make booleans always non-nullable and set a default if necessary.
Whenever I see null booleans in r3 apps, it´s usually because the app author, for whatever reason, later found that they need a third state (yes, no, something else). This is however not what booleans are for; when more than 2 states are required, a relationship input should be used.
This is the reason, why we have been reluctant to add a "go back to null" user action. It is bad design to have a null boolean in the first place; allowing users to switch back to it, makes it more tempting to app authors to use this bad third state on the frontend.
In your case, with the user checking whether a record is correct, you could:
- Use a relationship input with values such as
is correct, is not correct & not checked yet
- Use 2 booleans such as:
Record checked yes/no & Record is correct yes/no
- In this variant, you could hide the second boolean
Record is correct if the first boolean Record checked is not set to TRUE yet.
