A Mandatory Field Costs Less Than Inspecting Its Output: The Forcing-Function Math
In the proposal generator, one decision caused more pushback during rollout than any other: the document wouldn't assemble unless the owner's contact details and the full terms were filled in. Not a warning, not a red highlight — it simply wouldn't assemble.
The objection sounded reasonable: people would start typing garbage into mandatory fields just to get past them. Some did. But the share of documents that reached a client without contact details dropped to zero — because physical impossibility doesn't work like a reminder. It works like a property of the process.
A forcing function — a constraint that makes the wrong outcome impossible — costs less than downstream inspection not by a percentage but by an order of magnitude or more: it fires once, at design time, and after that it costs no time and no attention. Its limit is the point where the requirement itself starts producing garbage values; at that point the fix isn't to remove the field but to turn it into a pick list or an automatic calculation.
The arithmetic nobody bothers to run
The comparison isn't a matter of feel — it's labor cost per unit of output. Take one defect — missing contact details in an outbound document — and run it through three handling scenarios.
Scenario one: inspect after the fact. Someone reviews outbound documents and sends incomplete ones back. Cost: the reviewer's time on every document, plus the author's time to fix it, plus the delay before it ships. It's spent on every unit, forever.
Scenario two: a reminder. The system highlights the empty field but lets the user proceed anyway. Cost is lower, but so is the result: the share of defective documents drops, it doesn't hit zero, and whatever remains still needs the same after-the-fact inspection.
Scenario three: a forcing function. The document won't assemble without the field. Cost: one design decision and one conversation with the team at rollout. After that, the marginal cost is zero at any volume.
| Scenario | One-time cost | Cost per document | Residual defect rate |
|---|---|---|---|
| Inspect after the fact | None | Reviewer's and author's time | Depends on the reviewer's attentiveness |
| Interface reminder | Small | User's attention | Drops, but not to zero |
| Forcing function | Design decision plus one conversation | None | Zero for this defect |
| Training and instructions | Materials development | Employee's memory | Rises over time |
The difference between these rows isn't percentage points — it's structure: inspection cost scales with volume, a forcing function's cost is fixed. At a thousand documents a year the gap is measured in orders of magnitude, which is exactly why the argument over whether a hard stop is "too strict" usually happens without a single number on the table.
What happens to data with no gate at entry
The scale of the problem was measured with a method worth borrowing: not a survey, but a manual check of records in sequence.
Only 3% of organizations scored at an acceptable level on data quality, and 47% of newly created records contained at least one critical error.
I'll name the limitations myself: the sample is small and not random, the participants graded their own work, and the piece ran as a business-magazine column, not a peer-reviewed paper. The number matters not for its precision but for its timing — it measures the moment a record is created. An error at entry doesn't get corrected by reporting downstream. It flows straight into it.
Do mandatory fields actually work
The question is fair, because intuition says the opposite: people will find a way around it. Data from a field where record quality is critical enough to be studied gives an answer.
Mandatory fields, alongside templates and context-aware autofill, improved the completeness and correctness of data entered into electronic health records.
This is a review of other people's data, not a primary measurement, and it doesn't offer a pooled "completeness rose by X percent" figure — only a direction of effect; the full text is paywalled, so I worked from the abstract. The conclusion is accordingly cautious: mandatory fields improve completeness, and the size of the effect depends on context. And that improvement has a cost, covered below.
Where a forcing function breaks
A mandatory field isn't free. It has a predictable failure point, and it's worth knowing before rollout.
Garbage values. If a field is mandatory and the employee doesn't have the data, they'll type a period, a dash, or "TBD." The record is formally complete and practically useless. The tell: the share of identical short values in that field runs above a few percent.
Routing around it. The work moves to wherever the constraint doesn't reach — an email thread, a spreadsheet, a verbal agreement. This is the worst outcome, because now the defect doesn't just exist, it's invisible.
Blocking legitimate exceptions. Some cases genuinely can't have the field filled in. If there's no provided path for them, the forcing function starts getting in the way of real work, and it gets scrapped entirely — taking the useful part down with it.
All three problems get fixed the same way: don't remove the field, change its nature. Free text becomes a pick list, the value gets calculated automatically from other data, and exceptions get an explicit reason code for not filling it in — also from a list.
Why a constraint outperforms attentiveness
There's a theoretical basis for this, older than any information system: process reliability isn't set by how error-free people are, but by the number and quality of defensive layers.
Accidents don't come from a single human error — they happen when holes line up across several layers of defense at once. Latent conditions — system properties created by design decisions — can be found and removed proactively, before an incident, unlike active failures by people.
This work doesn't quantify cost and isn't about information systems — it's an explanatory model, and that's how I'm using it. The practical takeaway for our topic is direct: a latent condition removed at design time eliminates an entire class of future errors, while fighting active failures takes constant attention and never ends.
How to decide what to make mandatory
The second question saves the most. A large share of the fields people plan to make mandatory can actually be calculated from data that already exists — and then no entry is needed at all, and reliability beats anything a mandatory field could deliver. It's the same principle as in choosing between rules and a model: if the answer can be computed, a person shouldn't be the one typing it in.
The fourth node is the mandatory measurement. A forcing function with no follow-up check for garbage values turns into a source of false confidence: the records look complete, the reports get built, and the data inside them means nothing.
Four steps before you make a field mandatory
Count your current defect rate
Twenty of the last results, checked by hand. Without this number, the argument about strictness has no evidence in it.
Check whether it can be calculated
If the value can be derived from other data, you don't need a mandatory field — you need a rule.
Build a path for exceptions
An explicit reason code for not filling it in, chosen from a list. Otherwise the constraint gets scrapped entirely.
Measure garbage values a month later
A share of identical short values above a few percent means the field is mandatory in the wrong place.
If a defect can be made impossible, every dollar spent detecting it afterward is the price of one design decision you didn't make.
Questions people ask most
Should CRM fields be made mandatory?
Yes, for the data a record is meaningless without — usually three to five fields. Before you flip the switch, check two conditions: the employee actually has the data at the moment of entry, and the value can't be calculated from fields that already exist. If the second condition fails, what you need instead of a mandatory field is a calculation rule — it's more reliable and asks nothing of the person.
What do you do when people type garbage into mandatory fields?
Change the field's nature, not the requirement itself. Free text becomes a pick list; legitimate exceptions get an explicit reason code for not filling it in, also from a list. Garbage values are a signal that the employee genuinely doesn't have the data at the moment of entry, and the fix is changing when the field gets filled in, or where the data comes from.
Won't a hard stop trigger pushback?
It will, and that's a normal part of rollout. It gets defused two ways: an explicit path for legitimate exceptions, and an explanation of who actually gets hurt by the current defect. In our case, mandatory contact details meant the client had someone to ask a question — an argument that lands with the very account manager whose deal it ends up saving.
How much does the zero-defect result on contact details actually prove?
It's an internal result from one process at one company, not verified by an independent party. What's telling about it isn't the zero itself — with sending physically impossible without the field, that's trivial — it's that none of the earlier measures got there: not the instructions, not the reminder, not spot-checking outbound documents.
The mandatory-field mechanics in the proposal generator (the document wouldn't assemble without the owner's contact details and full terms) come from the product description of Alego.Digital, the author's own company. This is internal company material, not verified by an independent party, and is presented here as an illustration of the mechanism. The claim of zero documents sent without contact details applies to this specific service and follows from how assembly is built, not from a separate measurement. The classification of the three forcing-function failure points and the four-step sequence are the author's own generalization from practice, not formalized in the company's documents.
- Nagle T., Redman T. C., Sammon D. Only 3% of Companies' Data Meets Basic Quality Standards. Harvard Business Review, September 2017. hbr.org
- Madandola O. O. et al. The relationship between electronic health records user interface features and data quality. JAMIA, 31(1), 2024. academic.oup.com
- Reason J. Human error: models and management. BMJ, 320(7237), March 2000. bmj.com