Required fields by stage matrix

Most CRMs make fields required at creation because that is the only place the admin knew how to enforce them, so reps type 'TBD' into twelve boxes before they know anything about the deal. The fix is not fewer rules but better timing: require each field at the stage where the rep can actually know the answer, and only if a report or decision depends on it. This matrix makes that trade explicit, one field at a time.

Formats:
PDF + CSV + web view
Sections:
6
Updated:

What you get

  • A stage-by-field matrix marking each field as Required, Optional, or Locked at every opportunity stage
  • A 'why it earns its place' column that names the report, decision, or process that breaks without the field
  • Validation rule logic written in plain language so it can be built in any CRM
  • A field removal test for cutting requirements that nobody uses
  • An exceptions log for the rare deals that legitimately cannot meet a rule

Who it's for

  • CRM admins deciding which fields to enforce and when
  • Sales ops teams tired of placeholder values in pipeline reports
  • RevOps leaders tying stage definitions to data requirements

What's inside

  1. 1

    Required fields by stage

    8 columns, 6 worked example rows

  2. 2

    Why each field earns its place

    5 columns, 5 worked example rows

  3. 3

    Matrix standards

    5 fields to complete

  4. 4

    Field removal test

    8-point checklist

  5. 5

    Validation exceptions log

    6 columns, 1 worked example rows

  6. 6

    Why required-at-creation backfires

    Guidance notes

Preview of section 1

Required fields by stage

R = required to enter the stage. O = optional. L = locked for non-admins. Stage names are examples; replace them with your own pipeline stages.

FieldCreateQualifyDiscoverProposeNegotiateClosed WonClosed Lost
AmountORRRRLR
Close dateRRRRRLR

The preview shows part of section 1. The full template has all 6 sections (5 not previewed here), with blank rows ready to fill in. Download the full template

How to use it

  1. 1

    Start from the reports, not the page layout

    List the forecast, pipeline, comp, and board reports first, then write down every field they read. Those fields are your candidate required fields. Anything not on that list needs a named consumer before it can be required.

  2. 2

    Require each field at the earliest knowable stage

    Close date and amount can be estimated at qualification. Decision process and paper process cannot. If you require a field before the rep can know it, you get placeholder values that look like data and poison reports.

  3. 3

    Lock fields at Closed Won instead of just requiring them

    Amount, close date, and product lines should be locked for non-admins once a deal closes. Required-but-editable fields drift after booking, and that drift shows up in commission disputes three months later.

  4. 4

    Write validation rules that reject junk values

    A required text field accepts 'n/a'. Add rules for the obvious junk: close dates in the past on open deals, amounts of 0 or 1, and next steps shorter than a few words. Blank checks alone produce compliance, not data.

  5. 5

    Review the matrix every quarter and cut something

    Run the removal test in the checklist each quarter. If a required field has no consumer, or everyone fills it with the same value, drop the requirement. Every requirement you remove buys goodwill for the ones that matter.

Frequently asked questions

What fields should be required in a CRM?

Only fields that a report, process, or decision depends on. For opportunities that usually means amount, close date, next step, key contact roles, and a closed lost reason, each required at the stage where the rep can know the answer.

Should CRM fields be required at creation?

Very few. Close date and a record owner are reasonable at creation. Most qualification fields should be required when the deal enters the stage where that information is normally known, otherwise reps fill them with placeholders.

How do you enforce required fields by stage?

Use validation rules that fire when the stage field changes to a given value, plus page layout or path guidance so reps see what is needed before they try to move the deal. Test the rules against integration users so syncs do not fail.

How many required fields is too many?

There is no universal number, but as a rule of thumb, if a stage change needs more than four or five new fields, reps will start gaming it. Replace with your own data: check fill quality on each field and cut the ones filled with junk.

Related templates

All sales ops templates