Lifecycle Stage Is a High-Water Mark, Not a Status

Why HubSpot lifecycle stage is built to move forward only

HubSpot designed lifecycle stage as a one-way ladder. Stages are ordered, and the property is meant to advance. Move a contact backwards through a workflow or import and HubSpot will either refuse the change or let you do it only after you clear the value first. Clear it, and you also lose the "Became a [stage] date" timestamps that make conversion reporting possible.

That design is not a limitation to work around. It is the correct model, because lifecycle stage answers one question: how far did this person ever get? That is a historical fact, and historical facts do not get overwritten. The moment you reset a churned customer to Subscriber, you erase the evidence that they were ever a customer. Your Lead to Customer conversion rate quietly changes for every cohort that person belonged to.

The rule I install on every engagement: lifecycle stage is a high-water mark. It only moves forward, and anything that needs to move backwards belongs in a different property.

The three jobs you are overloading

When I open a lifecycle audit, I split the single dropdown into three separate concepts.

1. Funnel progress (lifecycle stage). The furthest point this person reached. Forward only. Drives conversion reporting and the "Became X date" properties.

2. Current status (a state property). Is this person active, inactive, churned, disqualified or recycled right now? This one is allowed to move in any direction because it describes the present, not the past. Name it for what it is: Member Status, Account Status, Engagement Status. Pick a name that a rep can read without a glossary.

3. Contact type (a classification property). Is this a buyer, a user, an employee of a customer, a partner contact, a journalist? This is an attribute of the relationship, not a funnel position, and it should never be encoded as a lifecycle stage.

Once those three live in three properties, most of the "lifecycle is broken" complaints disappear, because the thing that was broken was the design, not the data.

A real example of the split

On the Tech Barcelona HubSpot build, we hit this exactly. A member who cancels their membership stays at Customer in lifecycle stage, on purpose. The real current state lives in a separate Member Status property (Active, Inactive, Churn). When someone on the client team asked why a churned member still showed as Customer, the answer was that moving lifecycle backwards would have wiped out the record of who ever became a member.

The same project surfaced the contact type problem. Employees of member and partner companies had been mapped into Subscriber, which polluted the pool of people you could actually market to. The tempting fix was to push them all to Customer. We pushed back, because Customer today means "pays us", and the Members dashboard and conversion reporting read directly from that stage. Mixing non-paying employees into Customer would have destroyed the one number the exec team trusted. The cleaner move was to leave lifecycle alone, keep contact type in its own property, and build a list that excludes anyone who is already a member.

Same engagement, same lesson: when a reporting number matters, do not change what the stage means to solve a segmentation problem. Add a property.

The lifecycle stage audit (45 minutes, no workflows required)

You do not need to rebuild anything to find out how bad it is. Run these checks in order.

Check 1: Count the stages you actually use. Export contacts and group by lifecycle stage. If you have custom stages nobody has touched in a year, they are decoration. Delete or merge them. Every extra stage multiplies the ways records can disagree.

Check 2: Look for backwards writers. Open every workflow and import template that sets lifecycle stage. Anything that sets it to an earlier stage than the record's current one is either failing silently or running a clear-then-set routine that is stripping your timestamps. Log each one.

Check 3: Find the contradictions. Build a list of contacts at Customer with no closed won deal associated. Then the reverse: contacts with a closed won deal who are not at Customer. Both lists should be near empty. If they are not, your lifecycle is being set by hand or by integrations with no rules.

Check 4: Check the company rollup. Contact lifecycle and company lifecycle drift apart quickly. A company shows Subscriber while its main contact is a Customer, or the reverse. If you have never automated the rollup, assume it is wrong.

Check 5: Find who owns each transition. For every stage, ask who or what is allowed to move a record into it. If the answer is "anyone", "a form" or "I think Sam does it", that stage has no entry criteria. That is the real defect.

The fix, in the order that avoids damage

Order matters, because the wrong order means you clear data you cannot get back.

Step 1: Snapshot first. Export lifecycle stage and every "Became X date" property before you touch anything. This is your rollback.

Step 2: Create the status and contact type properties. Backfill them from what lifecycle was wrongly encoding. Churned customers get a status of Churn. Employees of customers get a contact type of Customer Employee. Do this before changing a single lifecycle value.

Step 3: Write entry criteria for each stage. One sentence each, testable, with a single owner. A record enters Opportunity when a deal is created in the sales pipeline, not when a rep feels good about the call. If you cannot test it with a filter, rewrite it.

Step 4: Automate transitions and delete manual ones. Stage changes come from workflows tied to the criteria, never from a dropdown a rep edits. Where a rep legitimately needs to override, route it through a request, not a field edit.

Step 5: Fix the company rollup. Company lifecycle should derive from its contacts and deals by a written rule, for example highest contact stage wins. Build it once as a workflow so it cannot drift.

Step 6: Correct the forward errors only. If a record is at a later stage than it earned, that is the one case that needs a deliberate cleanup, done in bulk with the timestamps preserved, and logged.

Step 7: Prove it with a reconciliation view. Keep a standing list of the contradictions from Check 3. If anything appears there, a rule failed. It is the same proof-filter logic we use to confirm that a blocked record source stays blocked.

What this changes in your reporting

With lifecycle as a high-water mark, three things get better immediately.

Your funnel conversion rates stop shifting under you. A cohort's Lead to Customer rate is a fixed number, because nobody can rewrite who got there.

You can finally answer "how many active customers do we have" from the status property and "how many people ever became customers" from lifecycle, and the two numbers are allowed to differ. That difference is your churn history.

And you stop using lifecycle stage as attribution. It describes progress, not where demand came from, and it changes as the record advances. Attribution belongs in its own immutable fields.

The blunt version

If your lifecycle workflow moves records backwards, you are not cleaning data. You are rewriting history and calling it hygiene. Keep the stage as a record of how far someone got, put the present tense in a status property, put the type of relationship in a classification property, and write down who is allowed to move each stage.

This is the same logic behind the lifecycle layer of our CleanOps Protocol and the lifecycle hygiene step inside our CRM Foundation and Data Architecture module. If you want a second set of eyes before you change anything, the GTM Maturity and Revenue Leak Assessment will tell you where your lifecycle data is leaking pipeline reporting, and what it costs you.