CRM Requirements: Which Fields Must Really Be Required

At some point in every CRM project, the field list lands on the table. Seventy properties, sometimes more. The question is not which ones you would like to have. The question is which ones become required.

That decision is almost always made from one perspective: the perspective of whoever receives the reporting. If you want to analyse how long a project runs from kickoff to handover, you make planned start and planned end required. The reasoning is sound. It just rests on an assumption that rarely gets checked.

A required field assumes that the person filling it in actually has the answer. In project businesses where a partner sits in front of you, they often do not.

The decision nobody records as a decision

Every CRM project has a two-hour session where fields get walked through. There are many of them, and at some point somebody starts ticking boxes. What happens in that session is rarely written down as a decision — it looks like configuration.

It is a decision about how people work. A required field is the one place in a CRM where the system stops a human and refuses to continue. Every tick is therefore a claim about what somebody must know at a given moment. HubSpot's own documentation puts it plainly: if a property is required, users cannot create or update the record until they set a value.

The reason this goes wrong so often is not carelessness. It is who is in the room. The people who need the reporting are there. The person who will fill that field twenty times a day usually is not.

We have written elsewhere about what a CRM rollout costs internally: what a CRM migration really costs your team. This piece is not about the effort. It is about one decision inside it — the one whose consequences last longest, because they live in the data rather than in the project plan.

The test question: does the person filling it in have the information?

There is one question that costs about thirty seconds per field and catches most of these mistakes:

Who fills this field, at what moment, and how do they know the value?

Three parts, and the third is where it breaks. A pattern that shows up repeatedly in project businesses: planned start and planned end are made required so that estimate can later be compared against reality. That works as long as the executing company deals with the end customer directly. The moment it is engaged through a partner, it simply does not know the date — it learns it late, often once the work is already running.

The field stays required. So it gets filled. With a date that looks plausible.

What a wrongly filled required field costs in reporting

The damage is not the single wrong number. The damage is that the analysis now measures something other than what its title says.

A variance analysis between planned and actual dates measures planning quality — as long as the planned dates are real. If half of them were typed to close a form, the same analysis measures data-entry discipline instead. Both reports look identical. Same heading, same axes, same colours. Only the question they answer has changed, and that is written nowhere.

Which leads to an uncomfortable but durable rule: an empty field is more honest than an invented one. An empty field is a visible state — you can filter on it, chase it, build an analysis that reports the gap. A filled field with nothing behind it is invisible and can never again be told apart from a real value.

Required on the record, or required from a stage

Most cases where a required field fails at creation resolve with a single distinction. The information is not unknown — it simply arrives later in the process.

Then the field does not belong on the record. It belongs to a stage. CRM systems support this: a property can be configured so it is only demanded once a record moves into a defined stage. The information stays mandatory — just at the point where it actually exists.

The last row is the one usually missing from the blueprint. Stage-level requirements apply to manual editing — not when a workflow or an import moves the same record. Anyone selling that rule as a data-quality guarantee is promising more than it delivers.

The handover point: from which stage does the record exist in the second system

The same argument repeats one level up as soon as a second system is involved — an ERP, a project or planning tool. The question is no longer which field is required, but from which stage the record appears in that second system at all. In group structures with several units on the same process this quickly becomes a group-wide CRM question, because every unit is used to a different handover point.

Both answers are defensible, and they carry different costs:

• Create early gives both systems a shared record number from the start. Everything that follows hangs off one key. The price: records that never turn into anything land in the second system too.
• Create late keeps unqualified records out and the second system clean. The price: until handover the same thing exists twice under two names, and somebody maintains both.

The choice hangs on one question: is the bigger risk junk data or double entry? In a business with many non-binding enquiries and few closes it is junk data — create late. In a business with few long-running records that several departments work on in parallel it is double entry — create early.

What does not decide this question is what the original blueprint said. The handover point is often inherited from a template written for a different business model and then treated as settled.

That real money sits at this seam is something we can show from our own projects. At aumico, the result of a cleaned-up process was not more fields but less friction on the way to a quote:

Neither number is an argument for more required fields. They are evidence that the system boundary, and the path across it, is itself a cost — which is why deciding where it sits is not a configuration detail.

Why a narrow test setup beats a complete field list

The usual order is: define all fields, then build, then test. It has a design flaw. A list of seventy properties cannot be judged at a table. Nobody can see in a spreadsheet whether a field is obstructive in a live record — you only see whether it sounds professionally sensible, and nearly every field does.

The detour that is faster: a narrow test setup covering only the contested step. Not the whole pipeline, not every object — the slice being argued about, with real records and the people who will actually work in it.

What a week of that teaches you and the list never will:

• Whether the value genuinely exists at creation or gets supplied later — visible in what people enter when they do not have it.
• Whether the stage you want to attach the requirement to is actually passed through cleanly in daily work, or routinely skipped.
• Whether the record appears in the second system too early or too late — visible where people start keeping parallel lists.

This is not an argument for skipping design work. It is a statement about which questions a blueprint can answer and which it cannot. Sequences, ownership and the object model belong in the blueprint. Whether a particular field is fillable at creation belongs in a live record.

The objection, and why it is right

Argue for fewer required fields and the same objection arrives reliably — and it is fair: the reasoning is not wrong, but it is hard to implement in practice; the question is not whether the data gets entered, it is how correct it ends up being.

Exactly. That is the question. And it is the reason for everything above, not a counter-argument to it.

Abolish required fields and you get empty ones. That is no improvement. But enforce them where the information is missing and you get filled fields with nothing behind them — which is worse, because it looks like a result. The alternative to “required everywhere” is not “required nowhere”. It is required where the answer exists, and one stage later where it only comes into being. Then completeness is enforced and correctness is possible.