Conditional logic must extend beyond enumerated fields: it should be standard functionality for any property type whenever a value is known or updated.
Right now, conditional logic only supports enumeration fields when a specific dropdown value is selected. That’s helpful, but far too limited for the complexity of modern revenue operations.
Example Use Case:
Leadership needs visibility into why a deal is being delayed -- whether the Close Date is pushed out of this quarter, into the next, beyond 90 days, or moved more than 30 days multiple times. While I’ve built workflows that trigger email and Teams notifications to the deal owner and leadership when the Push Reason is missing, those alerts arrive after the fact. By then, the behavior is already off-track.
Expecting reps to read a follow-up email or Teams ping every time they update a property is unrealistic and inefficient. That’s not a scalable compliance mechanism. It’s a workaround.
The only viable safeguard is inline enforcement.
Requiring dependent fields in real time, based on any property change, is table stakes for driving consistent CRM hygiene and pipeline accuracy. This isn’t a nice-to-have; it’s foundational for operational discipline.
And this is just one example—there are dozens more where behavioral enforcement depends on smarter, real-time field validation.
An additional example of conditional logic functionality that’s currently unavailable in HubSpot is the ability to dynamically surface deal properties based on the type of deal (or any other deal property) as it progresses from one stage to the next.
Current Limitation:
At present, HubSpot displays the same set of required stage properties across all deals, regardless of variables such as deal type. This limits our ability to tailor data capture to the context of the deal.
Example Use Case:
If the deal type is categorized as Upsell or Cross-Sell, we should require the rep to complete a custom property:
“Is this a Co-Terminus Deal?” (Defined as a deal that will share an end date with either the current or upcoming renewal.)
While it’s technically possible to create read-only properties that are updated via workflow and then used to block stage advancement, this is an inelegant and inefficient workaround. It creates unnecessary admin complexity, lacks transparency for the end user, and reduces flexibility for future iterations.
Totally agree, enforcement of deal process at the time using conditional logic would be way more impactful than sending notifications/tasks that build up or risk getting ignored.
The current conditional logic is too restrictive for our needs and it would be great to see this function across all properties. It would make such a difference to the data hygiene and day to day management of the deal pipeline.
This would be a game changer and only enforce our data’s integrity. Making a field required when values in another field are met would force compliance in the moment, and should be available for fields across objects.
Hi everyone, I’m Rachel, the PM for properties.
Thank you all for taking the time to submit, upvote, and comment on this Idea. I’m happy to report that Date-based conditional property logic (e.g. Date/Datetime as a controlling property) is In Development! This means that our engineers are actively building this feature.
The product development process is always filled with unexpected bumps and hurdles, so I can’t give a timeline, but I am confident in saying we’ll deliver this feature as soon as possible. All updates will be relayed on this thread, so stay tuned!