How to require deal fields before a stage change in HubSpot

How do you make reps fill in key deal fields before a stage change in HubSpot?

Use conditional stage properties on the deal pipeline. In HubSpot's pipeline settings, you add a rule to a stage, pick the properties that should appear, and tick Required on the ones that matter. HubSpot then asks for those values when a user manually creates a deal in that stage or moves a deal into it.

This tutorial is for a specific situation: a small B2B team, often founder-led, where deals reach Closed Won with half the useful information missing. Nobody knows why the deal was won, what the buyer was replacing, or who signed. Three months later, the data you need for forecasting and positioning simply is not there.

The fix is not a lecture about CRM hygiene. It is a small, targeted rule that asks for the right field at the right moment. I will walk through the setup, then spend most of the article on which fields to require and where, because that is where teams usually go wrong.

What are conditional stage properties in HubSpot?

Conditional stage properties are pipeline rules that show selected properties when a deal enters a specific stage. HubSpot describes the feature as showing certain properties when users manually create a record in or move a record to a specific stage. Marking a property as required blocks the change until the field is filled in.

HubSpot's documentation is direct about the required behavior: if a property is required, users cannot create or update the record until they set a value for it. That is the whole point. The rule turns a field from optional homework into a gate the deal has to pass.

Note the word manually. The help article frames this feature around people creating or moving records by hand. If deals in your account also move through workflows, imports, or integrations, test how those paths behave before you rely on the rule as your only safeguard.

What do you need before you start?

You need a HubSpot user with edit property settings permissions, which HubSpot lists as required for this setup. You also need the properties themselves to exist already. Create any custom deal properties first, such as a primary competitor or a reason won, then come back to the pipeline settings to attach them to stages.

Check your subscription too. HubSpot's article on this feature does not state the plan requirement on the page I reviewed, and pipeline features vary by tier. If you do not see the conditional logic option in your pipeline settings, check HubSpot's current product and plan documentation.

Finally, write down your pipeline stages and what should be true of a deal at each one. Ten minutes with a plain document now saves an hour of rearranging rules later.

How do you set up a required property on a deal stage?

Open settings, go to Objects under Data Management, choose Deals, and open the Pipelines tab. Click the pipeline you want to edit. In the row of the stage, hover over the Conditional logic rules column and click Add rule. Add the property, tick Required, and click Save logic.

In more detail, the path HubSpot documents goes like this. Click the settings icon in the top navigation bar. In the Data Management section, click Objects. Use the Select an object dropdown to choose Deals. Then click the Pipelines tab and click the name of the pipeline you want to change.

Each stage appears as a row. Find the stage where you want to collect information, hover over its Conditional logic rules column, and click Add rule. HubSpot asks you to choose an operator for the rule. Then, in the Dependent properties section, click Add property and select the property you want to show.

Tick the Required checkbox for any property that must be filled in. Leave it unticked if you only want to prompt for the field without blocking the move. Repeat for each property you want on that stage, then click Save logic in the upper right.

Which properties should you require at which stage?

Require each field at the earliest stage where a rep can honestly know the answer, and not before. Asking for a contract value at first meeting invites made-up numbers. Asking for the reason won at Closed Won is perfect, because the rep knows it then and may forget it within a week.

Here is how I would map it for a small B2B team. At the qualification stage, require the problem the buyer is trying to solve and the current alternative they use today. Those two fields feed positioning, and a rep who cannot fill them in has not really qualified the deal.

At the proposal stage, require the expected close date and the deal amount, since a proposal makes both concrete. At Closed Won, require the primary reason won and the main competitor or alternative considered. At Closed Lost, require the reason lost. That last one is the field teams skip most and need most.

The alternative and competitor fields connect directly to lead scoring and messaging work. If you are building scores on top of these fields, my walkthrough on building a three-property lead score in HubSpot shows how a few clean properties go further than many messy ones.

How many required fields is too many?

Two or three required fields per stage is a sensible ceiling for a small team. Past that, reps start entering placeholder values just to move the deal, and the data gets worse, not better. A short list of fields that are always filled in beats a long list that is filled in with junk.

Use dropdown properties wherever you can. A reason won field with six clear options is easier to fill in and far easier to report on than a free text box. Free text is fine for one notes field, but your reporting will thank you for structured choices.

Review the rules after a month. Look at the values reps actually entered. If one option dominates, or "other" is the most common answer, the options need work. The rule is only as good as the choices it offers.

How do you test that the rule works?

Create a test deal, then try to move it into the stage with the rule without filling in the fields. HubSpot should show the properties and stop the move until the required ones have values. Then fill them in, complete the move, and check that the values saved on the deal record.

Test from the deal record and from the board view, since reps use both. If your team moves deals any other way, such as through a workflow or an integration, run a test through that path as well. You want to know before go-live which routes the rule covers in your account.

Delete the test deal afterward, or keep a clearly named test pipeline for future checks. Test records that linger in a live pipeline distort reports, which defeats the purpose of the whole exercise.

What mistakes should you avoid with required stage properties?

Avoid requiring fields reps cannot know yet, requiring free text where a dropdown would do, and adding rules without telling the team. Also avoid treating the rule as your only data quality control. If deals can move through automation or imports, those paths need their own checks.

The communication mistake is the easiest one to underestimate. A rep drags a deal, a form appears, and they feel blocked rather than helped. A two-minute note explaining why each field exists, and how the data will be used, changes how the rule lands.

Data quality also depends on clean records upstream. If your contacts are duplicated, the deals attached to them inherit the mess. I covered that problem in how to merge duplicate CRM contacts without breaking automations.

What should you do next?

Pick one stage, usually Closed Won or Closed Lost, and add one or two required dropdown properties today. Test the rule with a dummy deal, tell your team why the fields matter, and review the answers after a month. Then extend the same approach to earlier stages, one stage at a time.

Starting small keeps reps on side and gives you clean data quickly. Once the reason won and reason lost fields fill up, you will have something most early-stage teams lack: a record of why buyers actually choose you.

If you want help designing a HubSpot pipeline that collects the data your GTM motion needs, reach out. I build CRM systems and the automations around them for B2B teams, and I am happy to look at your setup and suggest where to start.