A required field does not make a record usable. Define the business decision, its required evidence, the person accountable for accepting that evidence and the consequence of missing data before changing CRM validation rules.
Data quality is a decision-specific requirement
Suppose a services company asks its CRM partner to make an expected service start date mandatory. The request sounds precise, but there are several possible reasons for the field: Sales may need to forecast contract start dates; Operations may need to reserve engineers; Finance may need to recognise a billing trigger. These decisions use the same label but do not necessarily require the same definition or timing.
For Sales forecasting, an estimated date may be sufficient. To commit an engineer to a customer, Operations may need a confirmed start window, agreed scope and a named delivery owner. A single mandatory field cannot establish all three facts. It can only require that something be entered.
Write the decision contract before designing a control
| Question | Example answer | Design consequence |
|---|---|---|
| What decision is made? | Can Operations reserve a service slot? | Use operational acceptance as the point of control, not a generic sales-stage update. |
| What evidence is necessary? | Confirmed window, location, agreed work, capacity requirement. | Store the values at the job or commitment level if one deal contains several jobs. |
| Who supplies the evidence? | Sales confirms customer commitments; Operations confirms capacity. | Separate responsibility for submission from authority to accept. |
| What does valid mean? | Location and work type recognised; capacity checked before acceptance. | A non-empty value is not necessarily an admissible value. |
| What happens if it is missing? | Request clarification; do not confirm the start date. | Define the exception path and who can resolve it before enforcing workflow automation. |
The business owner of the decision should determine what evidence is sufficient. A CRM administrator can implement the rule; that does not make the administrator accountable for the operational risk of accepting an invalid commitment.
Distinguish data defects from control defects
When a CRM report is unreliable, I would test four separate conditions before proposing a new field, validation rule or integration.
- Definition: do two functions use the same term for different events? A “start date” may mean commercial signature, planned mobilisation or first actual visit.
- Capture: does the information originate at an identifiable operational event? If nobody has the information when the CRM asks for it, mandatory capture will encourage placeholders.
- Authority: who can challenge or reject the record when it is not fit for the decision? Reporting ownership is not automatically decision authority.
- Use: does the quality problem cause a recognisable decision failure, or is the field merely incomplete in a dashboard?
These questions can identify different interventions. An ambiguous definition requires agreement between functions. Late capture may require a changed handover. Data held reliably in a field-service platform may require access rather than duplication. A true missing event may justify new capture in an operational system.
Three outcomes, not one default implementation
| Finding | Recommended next step | What not to assume |
|---|---|---|
| Reliable information already exists in the system that owns the process. | Verify who needs it, for which decision and whether authorised access is adequate. | Do not replicate it in CRM only to make another report complete. |
| The relevant event exists, but the business has not agreed who captures or accepts it. | Define event, owner, acceptance rule and exception handling. | Automation cannot allocate the missing accountability. |
| The operational event is defined and ownership is agreed, but the system cannot capture or transmit it. | Investigate a data-model change, workflow rule or integration. | Do not specify the platform until the event lifecycle and source of truth are clear. |
How this becomes an Intervention Candidate
A candidate should state the business decision affected, observable evidence of the failure, the current data source, the responsible functions and the test that could disprove the need for new software. For example: “Service start commitments may be accepted without capacity confirmation. Verify whether Operations already runs a separate acceptance process before proposing CRM stage-gates.”
If that acceptance process already works and its information is available when needed, the candidate may be rejected. The absence of a CRM field alone is not justification for a project.
Related: Classify a CRM coverage gap · Sales-to-service handover: define the operating rule.
Scope of the note. This is a diagnostic framework, not a finding about any particular client. Examples are illustrative. Evidence from the actual client and system is required before recommending implementation work. Method and responsibilities.
Reference: ownership is a business responsibility
The UK government's data ownership model distinguishes data-owner accountability from technical custodian responsibilities. A private business may use different job titles, but the underlying distinction matters: the person configuring a field is not automatically the person entitled to decide what the field means or when it must be complete.