How I Built a Dynamic ‘Today’ Date in HubSpot to Solve a Deal Launch-Date Reporting Problem

Have you ever tried to answer a seemingly simple question in HubSpot: "How many days are left until this deal launches?" Or "How many deals were supposed to launch in Q2 but actually moved to Q3?"

You might assume this is straightforward. You have a Launch Date property, after all. Just compare the Launch Date with today.

But there is a problem.

What exactly is "today" in HubSpot?

HubSpot gives you plenty of date properties — Create Date, Close Date, Lifecycle Stage dates, and custom date properties as per your requirement (such as the Launch Date). But when you need a reusable CRM property representing the current date, things become considerably more interesting.

I ran into exactly this problem while building a solution for a real-world business case.

The Business Requirements

The client had Deals with a Launch Date. They wanted to answer questions such as:

• How many days until a Deal launches?
• Is the Deal launching this quarter?
• Was the Deal originally expected to launch in Q2 but moved to Q3?

Almost every one of these calculations requires the same thing: today's date. And that's where the interesting part begins.

The Obvious First Step

Diving into the solution, the obvious first step is to create a date property called Today's Date on the Deal object that represents the current date, and use that property as the reference point for downstream calculations.

The catch? The date property doesn't magically update itself every morning (kinda hoping it did 😶).

So I had to build a mechanism using HubSpot workflows to keep the value set to the current date.

Why One Workflow Wasn't Enough

After creating the property, I built a Deal-based workflow around it.

The idea was simple: whenever the Today's Date property was known or unknown, the workflow would set it to the current date and time on the Deal record. Then I added a 24-hour delay. The Deal would sit there for 24 hours and, once released, the workflow would update the property again with the next day's date.

Simple enough, right?

At this point, I confronted an unexpectedly nuanced difficulty that demanded prolonged, exasperated reflection before its cause became clear.

HubSpot workflows operate extremely fast. When a Deal reached the end of that 24-hour delay, HubSpot would release the record and immediately evaluate the enrollment criteria again. Since the Deal's Today's Date was now known, it qualified for re-enrollment.

And that is exactly what I wanted! The Deal should continuously cycle through the workflow, updating its Today's Date every 24 hours.

But when I looked at the workflow action logs, I noticed something strange.

Let's call the Deal Deal X.

Deal X would be released from the 24-hour delay. Almost immediately, HubSpot would enroll it back into the same workflow. But at that exact moment, the record was technically still in the workflow.

So HubSpot essentially said:

"This record is already in this workflow. Enrollment skipped."

And there was the problem.

The record would eventually become unenrolled, but the re-enrollment attempt had already been skipped. Deal X was now out of the workflow, which meant its Today's Date would never get updated again for that Deal.

In other words, my seemingly simple "update the date → wait 24 hours → update it again" mechanism had a race-condition-like behavior.

And that led me to the first major realization of this solution.

The Solution: Introducing a Helper Workflow

To overcome the timing issue caused by simultaneous unenrollment and re-enrollment, I introduced a second workflow — a helper workflow.

This second workflow was intentionally simple. It had no enrollment triggers, because it was designed to be called directly from the first workflow. It contained only two actions:

1. A 5-minute delay
2. A "Set property value" action to update the Today's Date property

I also modified the first workflow.

Instead of sending the Deal directly back through the same workflow, I added a branch that checks whether the Today's Date is known. If it is, the Deal enters a delay that runs until 12:15 AM, just after midnight. Once that delay is complete, I use the "Go to workflow" action to send the Deal to the second, helper workflow.

This solved the original timing problem because, by the time the Deal enters the second workflow, it has already left the first workflow. There is no longer a situation where HubSpot is trying to re-enroll a record while it is technically still inside the same workflow.

But there was another small problem to solve...

If hundreds of Deals reached the helper workflow around midnight, they could all potentially execute the property-update action at the same time. This may lead to the same problem, where every record is being unenrolled and enrolled at the same time.

That's why I added the 5-minute delay (it can be less as well) to the helper workflow.

The delay creates a small amount of processing separation between records, so the property updates are naturally spread out rather than having every Deal hit the update action at the exact same moment.

So the overall flow became:

Workflow 1 → Wait until after midnight → Go to Workflow 2 → Wait 5 minutes → Update Today's Date → Re-enroll to Workflow 1

This relatively small change solved the original issue. More importantly, it separated the two critical operations: leaving the first workflow, and updating the date for the next cycle.

The first workflow was no longer trying to immediately re-enroll a Deal that HubSpot still considered active. The helper workflow handled the update separately, giving the Deal a clean path to re-enter the first workflow on the next cycle.

The Result

In the end, this solved the problem I started with: having a reliable, continuously updating "Today's Date" reference inside HubSpot. With that foundation in place, the Launch Date on each Deal could now be compared against the current date to calculate how many days remained until launch, identify whether a Deal had moved into a different quarter, and build the reporting logic the business actually needed.

What initially looked like a simple date calculation turned out to be a workflow timing problem — but separating the process into two workflows gave me a reliable way to make it work.