We have 2 pipelines with identical pipelines for different areas of the business, and from time to time, we have to move deals between these pipelines. Despite having identical stages when a deal moves between pipelines, it automatically reverts to the first stage of the pipeline and triggers one of our workflows.
Is it possible for the deal stage to be carried over between pipelines? Note that our criteria for switching pipelines can’t be automated within HubSpot.
Hi @AStu21,
If pipeline stages are identical between the pipelines, you could consider consolidating them. Identical stages are typically a sign that only one pipeline should be used. (There are more considerations to this, such as pipeline access.)
Even when pipeline stages have the same name, they have different identifiers in the background and HubSpot does not consider them identical. There is no way to configure them like that either.
If you don’t want workflows to fire when you move a deal from one pipeline to another, you would have to update your workflow enrollment criteria, e.g. filtering for the “Date entered [stage ID]” value.
For example, if you move a deal from pipeline A to B, you could specify that the “Date entered [stage from pipeline A]” must be unknown in a workflow.
If you need more nuance, you might have to create an additional custom property that you need to update before moving a deal to another pipeline and the value of which blocks them from entering certain workflows.
Best regards!
Hi @AStu21,
Karsten’s explanation is spot-on, even if stages share the same name, they have different internal IDs per pipeline, so HubSpot will always treat them as distinct. That’s why the deal resets to the first stage when switching pipelines and why workflows fire.
One additional architectural lens to consider (especially since your pipeline switch can’t be automated) is controlling workflow enrollment rather than trying to preserve stage position.
Common patterns teams use here:
1. Stage-entry conditions in workflows (e.g. using Date entered [specific stage] is known/unknown) so workflows only fire on “true progression,” not pipeline transfers.
2. A temporary control property (manual toggle or status flag) that’s set before moving the deal, which workflows check before enrolling. This gives you intentional control without changing pipeline logic.
3. As Karsten mentioned, if pipelines are structurally identical long-term, it’s also worth revisiting whether separation is needed beyond permissions or reporting context.
Net-net: deal stage carryover across pipelines isn’t supported by design, but you can safely prevent unwanted automation by tightening workflow conditions around how and when a stage change should be considered meaningful.
Hope that adds another angle to your decision-making.
Best,
Joeniel
Drafted with AI assistance, reviewed and validated by me.