Short answer: lifecycle stage places a contact or company in your overall funnel (Subscriber, Lead, MQL, SQL, Opportunity, Customer, Evangelist, Other). Lead status is a sub-stage that describes what sales is doing with a record while it is a sales qualified lead (New, Open, In Progress, Attempted to Contact, Connected, and so on). HubSpot’s default automation, imports, forms, the API, the Salesforce integration and workflows only move lifecycle stage forward. To move a record back, you clear the value first and then set the earlier stage, either by hand or in a workflow. Doing that clears the legacy “Became a [stage] date” for the later stage, so report on the newer date-entered and date-exited properties instead.
For marketing ops, RevOps and sales ops owners of a HubSpot portal where marketing and sales disagree about what an MQL is. Last reviewed October 2026 against HubSpot’s knowledge base.
1. Two properties, two different questions
Most arguments about “the funnel” in HubSpot are two properties being read as one.
| Lifecycle stage | Lead status | |
|---|---|---|
| Question it answers | Where is this record in our whole marketing-to-customer process? | What is sales doing with this record right now? |
| Who should write it | One rule set, owned by marketing ops or RevOps | The rep working the record, or sales automation |
| Default values | Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist, Other | New, Open, In Progress, Open Deal, Unqualified, Attempted to Contact, Connected, Bad Timing |
| Direction | Forward only for automation | Moves freely |
| Good for reporting | Funnel conversion and velocity between stages | Rep activity and queue health |
HubSpot’s own definition is the useful one: lead status describes the sub-stages within the sales qualified lead stage. It is not a second funnel. When a team adds “MQL – Rejected” or “SQL – Nurture” as new lifecycle stages, it is usually trying to express something lead status (or a custom reason property) already holds.
2. Why lifecycle stage only moves forward
HubSpot’s default behaviour is that automatic updates to lifecycle stage only advance it. The same is true when the value is written by an import, a form submission, an API call, the Salesforce integration or a workflow. If a record is a Customer and a workflow tries to set it to Lead, nothing happens, and nothing tells you it didn’t.
That rule exists to protect funnel reporting: a form fill from an existing customer should not knock them back to Lead. The side effect is that legitimate backward moves (a closed-lost opportunity recycled to nurture, an MQL sales rejected) silently fail unless someone designed for them.
Two symptoms tell you this is happening in your portal:
- Contacts sit in Opportunity long after their deal closed lost, because the recycle workflow “ran” but could not move them.
- The MQL count never shrinks, because rejected MQLs have nowhere to go except a stage they are not allowed to return to.
3. How to move a record back safely
There are two routes, and both work.
By hand. You can edit the lifecycle stage on a record to an earlier value. HubSpot allows this for manual edits.
In a workflow (Professional or Enterprise). Use two “Set a property value” steps, or clear and set:
- Clear the lifecycle stage property.
- Add a short delay so the clear is committed before the next write.
- Set the earlier stage.
Enrol on a specific, documented trigger (for example “associated deal moved to Closed Lost and no other open deals”), not on a broad list, and log the reason in a custom property so the move can be audited later.
Before you build it, write down which backward moves are allowed. A typical, defensible set:
- Opportunity → Lead or MQL when every associated deal is closed lost.
- MQL → Lead when sales rejects with a reason.
- Never backwards from Customer, unless the account has churned and you have a separate churn process.
4. What a backward move does to your reporting
This is the part most teams miss. HubSpot keeps two kinds of stage dates:
- The legacy “Became a [stage] date” properties. When you manually move a record to an earlier stage, HubSpot clears the “Became a” date for the later stage.
- The newer calculated stage properties (date entered and date exited each stage). These are not cleared by a manual backward move.
So a funnel report built on “Became an Opportunity date” will lose history every time someone recycles a record, and the conversion rates will drift upward for reasons nobody can explain. Build funnel and velocity reporting on the date-entered and date-exited properties instead, and treat “Became a” dates as a convenience field, not a source of truth.
5. A lifecycle and lead-status setup that holds
What we would put in place on an inherited portal, in this order:
- One writer for lifecycle stage. Turn off or retire every workflow, form default and integration setting that writes the property except one documented set of rules. Multiple writers is the root cause in most broken funnels.
- Definitions in writing, signed off by sales. What makes an MQL, what makes an SQL, and the exit criteria for each, kept somewhere both teams can find.
- Lead status for the sales sub-stages. Use the default values or a short custom list, and keep it inside SQL.
- A reason property for rejections. A dropdown such as “MQL rejection reason” carries the detail that people otherwise try to squeeze into new lifecycle stages.
- Explicit backward moves. The clear-then-set workflow from section 3, with the allowed moves listed in its description.
- Reporting on calculated stage properties. Date entered and date exited, never “Became a”.
6. A ten-minute check you can run today
- Open a sample of 20 contacts whose deals closed lost last quarter. How many are still in Opportunity?
- List every workflow that sets lifecycle stage (filter workflows by the property in their actions). If the answer is more than two, you have more than one writer.
- Open your main funnel report. Is it built on “Became a” dates? If so, the history has been edited every time anyone recycled a record by hand.
If any of the three answers surprises you, the lifecycle model is the first thing to fix, before scoring, routing or attribution, because all three read from it.
Questions we get asked
Can I create custom lifecycle stages? Yes, but most requests for new stages are really requests for a reason field or a lead status value. Add stages only when the funnel itself has a step the defaults do not describe.
Should lead status live outside SQL? HubSpot defines it as a sub-stage of SQL. Using it across every stage turns it into a second funnel nobody can report on.
Does the Salesforce integration respect the forward-only rule? Yes. Writes from the Salesforce integration can only advance the default lifecycle stage property, which is why a lead sent back in Salesforce often stays put in HubSpot.
Related reading: an inherited HubSpot portal: the first 30 days, the HubSpot audit checklist and our lifecycle and lead routing rebuild.
Source: HubSpot Knowledge Base, “Use lifecycle stages” (checked 20 October 2026).