Lifecycle stages on contacts and companies

Every contact and company carries a lifecycle stage: where that person or account sits in the funnel, independent of any one deal. New records start at Lead. You can change the stage inline in the Contacts and Companies lists, or from the Edit dialog on a record page.

• Lead — a name you have, nothing qualified yet.
• MQL — marketing qualified: they have shown interest (a form, a download, a booking).
• SQL — sales qualified: a rep has confirmed there is a fit and a conversation.
• Opportunity — there is an open deal.
• Customer — they have bought.
• Evangelist — a customer who refers others.
• Churned — a former customer. This sits outside the funnel order.

Stages only move forward

A stage can be advanced by anyone who can edit the record. Moving it backward (for example Customer back to Lead), or into or out of Churned, is refused: the save is rejected with a message naming the move, and none of the other fields in that save are written either. Setting the same stage again does nothing. This keeps a record's history honest: nobody can quietly demote a customer, and an automation can never undo a rep's qualification.

Admin override with a reason

1. Open the record and click Edit.
2. Choose the earlier stage (or Churned). A "Reason for moving the stage back" box appears; it only appears for admins.
3. Write the reason and save. The reason is stored in the record's lifecycle history with your name and the date.

If you are not an admin, the dialog tells you up front that the stage only moves forward, so you do not fill in a form only to lose it. An admin who is viewing as someone else still holds the override; the person being viewed as does not gain it.

Changing many records at once

Tick the checkboxes beside several contacts or companies and choose Set lifecycle stage from the bar that appears at the bottom of the list. Pick the stage (Churned is not offered here) and the dialog tells you, before anything is saved, how many records will move, how many are already there, and which ones will stay put because the stage only moves forward. Each record is then judged on its own: records that can advance do, and the ones that stayed put are named again in the confirmation. A bulk change never overrides. To move a record back, open it and use the Edit dialog, where an admin can give the reason.

Automations that follow a stage change

A workflow can start when a stage changes: pick the "Lifecycle stage changed" trigger, choose contacts or companies, and optionally the stage it must move to (for example, create an onboarding task when a company becomes a customer). It fires for changes people make, alone or in bulk. A change made by another workflow never fires it, so two automations cannot set each other off.

A workflow can also set the stage itself, with a Set property step on Lifecycle stage. The same rule applies as for people, with no exceptions: the step only ever moves a record forward. A step that would move it back, or to Churned, is skipped, the run keeps going, and the run's log says which stage the record had and why the step did nothing. Stage changes a workflow makes appear in the record's history with the workflow named.

Moving records forward automatically

An admin can have three everyday events move records forward on their own, per brand, under CRM settings → Lifecycle: a form is submitted, a deal is created, and a deal is won. Each one can move contacts, companies, both or neither, to a stage you pick, and every rule is off until you pick one. A won deal making its contacts and its company Customers is the usual first rule; a submitted form making an existing contact an MQL is the second.

These rules follow the same forward-only law as everything else: a customer who fills in a form again stays a customer, a churned record is left alone, and nothing is ever moved back. They only apply to records that already existed. A contact created by the submission starts as Lead as before, whatever the form rule says. A change made by a rule appears in the record's history with the event named (the form, or the deal) and no person, and it starts "Lifecycle stage changed" workflows like a change a person makes. Imports never trigger these rules.

Merging two records

When you merge a duplicate into a record, the lifecycle stage is not one of the fields you pick side by side: the higher stage is kept automatically, whichever record holds it, and the merge preview says so under the row. The one case with no automatic answer is Churned against a funnel stage, because Churned is not a step on the funnel. The preview then asks you to pick which stage to keep before the merge can go ahead. Keeping this record's stage needs nothing more; keeping the duplicate's stage moves the surviving record off the funnel (or back onto it), so only an admin can choose it. A merge that changes the stage is recorded in the history with the merge as the reason.

Imports and the HubSpot sync

An import treats the other system's stage as evidence, not as an instruction. A new record takes the stage from the file or from HubSpot as its starting point. An existing record only moves forward: if the file says Lead about someone you have already marked Customer, the rest of the row is still imported (phone, title, address) and the stage stays Customer. A stage that is not a funnel step, such as Churned, is treated the same way. Nothing is counted as an error; the import result lists each record whose stage was kept, so re-running last year's export can never drag your customers back to Lead.

The same rule applies to the continuous HubSpot sync (the sync summary counts the stages it kept) and to the migration hub, where a kept stage appears as a warning on that row. Stage changes an import makes are recorded in the record's history with the import named and the person who ran it; the automatic sync records no person. If HubSpot is right and Verbial is wrong, an admin moves the record back from its Edit dialog with a reason.

History

Every stage change is recorded: from, to, who, when, and how it happened (a manual edit, an import, a merge or an automation). Override reasons live only in that history, never in the audit log, so they can contain frank notes. Merging two records carries the history to the surviving one, and an admin's contact export includes it.