HubSpot’s workflow tool includes a clone button. One click, and you have an exact copy of your workflow, ready to modify. It is one of the most useful features in the platform for teams that build variations on proven automation. But that clone button has a hard boundary: it only works within the same portal.
The moment you need that same workflow in a different HubSpot account — whether it is a client portal, a regional instance, or a newly acquired company’s system — you are in fundamentally different territory. The mechanics change, the risks multiply, and the approach requires far more planning.
- One-click, takes seconds
- All references stay valid
- Zero dependency issues
- No tooling required
- No native support
- Every ID must be remapped
- Dependencies can silently break
- Requires tooling or manual work
This guide provides a direct comparison of same-portal and cross-portal workflow cloning, explains why the difference matters, and offers practical guidance for handling both scenarios.
How Same-Portal Cloning Works in HubSpot
HubSpot’s native cloning feature is straightforward and reliable. Understanding what it does well sets the context for why cross-portal cloning is harder.
The One-Click Clone Process
Navigate to Workflows
Go to Automation > Workflows in your HubSpot portal.
Select the Workflow
Hover over the workflow you want to clone and click the "More" dropdown.
Click Clone
HubSpot creates an identical copy in a draft (turned off) state.
Rename and Modify
Rename the cloned workflow and adjust as needed for your new use case.
The entire process takes seconds. The cloned workflow includes every action, branch, delay, and setting from the original.
What Gets Cloned vs. What Does Not
| Element | Cloned | Not Cloned |
|---|---|---|
| All workflow actions in exact sequence | Yes | |
| If/then branch logic with filter criteria | Yes | |
| Delay settings (type and duration) | Yes | |
| Internal notifications with recipients | Yes | |
| Go-to actions, goal criteria, suppression lists | Yes | |
| Re-enrollment settings and rules | Yes | |
| Workflow name (gets "(Copy)" suffix) | No | |
| Enrollment history (starts at zero) | No | |
| Performance data (open rates, conversions) | No | |
| Active status (always created as draft) | No |
Common Use Cases for Same-Portal Clones
Teams most frequently clone within the same portal for:
A/B Testing Variations
Clone a workflow, change one variable (delay length, email content, branch criteria), and run both versions against different segments to measure performance.
Lifecycle Stage Variations
Create an Enterprise prospect nurture based on a proven SMB nurture by cloning and adjusting the criteria and messaging.
Seasonal Campaigns
Clone last quarter's campaign workflow and update the content for the new quarter, keeping all the proven logic intact.
Team-Specific Routing
Clone a lead routing workflow and adjust assignment rules for a different sales team or region.
Why Cross-Portal Cloning Is Fundamentally Different
The simplicity of same-portal cloning creates an expectation that moving workflows between portals should be similarly easy. It is not. The difficulty is rooted in how HubSpot’s data architecture works.
The Internal ID Problem
Every object in HubSpot has an internal ID that is unique to its portal. When you clone within the same portal, all IDs remain valid because they reference objects in the same database. A workflow action that sends email ID 12345 continues to work because email 12345 exists in the same portal.
When you move to a different portal, email ID 12345 either does not exist or refers to a completely different email. The same applies to:
Every one of these references must be resolved in the target portal for the workflow to function.
No Native Export/Import
HubSpot does not offer a workflow export file that can be imported into another portal. There is no JSON download, no template marketplace for workflows, and no cross-portal sharing mechanism in the product. This is a deliberate architectural decision: workflows are deeply coupled to their portal’s data schema.
Dependency Depth
A simple workflow might reference 2-3 dependencies. A complex marketing automation workflow can easily reference 15-20 distinct objects:
Plus 2 forms, 1 pipeline with 6 stages, and 3 team/owner references. Each of these dependencies may have its own dependencies. An active list might filter on a custom property. A marketing email might contain a CTA that links to a landing page. The dependency tree can go several levels deep. For a thorough exploration of these dependency chains, see our workflow dependencies guide.
Side-by-Side Comparison
Here is a direct comparison across the dimensions that matter most to HubSpot administrators.
| Dimension | Same-Portal Clone | Cross-Portal Clone |
|---|---|---|
| Native support | Yes, one-click | No native support |
| Time required | Seconds | Hours to days (manual) |
| Dependency resolution | Automatic (same IDs) | Manual mapping required |
| Risk of broken references | None | High without proper mapping |
| Enrollment triggers | Preserved exactly | Must be rebuilt with target IDs |
| Email actions | Reference same emails | Emails must exist in target |
| Property references | All valid | Must verify existence and type |
| List references | All valid | Must be recreated or mapped |
| Testing required | Minimal | Extensive |
| Tooling needed | None | API tools, mapping, or Jetstack |
| Rollback complexity | Delete the clone | Must undo all created assets |
Dependency Mapping: The Critical Step for Cross-Portal Cloning
Before attempting to recreate a workflow in another portal, you must map every dependency. Skipping this step is the most common cause of failed cross-portal cloning attempts.
Step 1: Extract the Dependency Inventory
Open the source workflow and systematically document every external reference. Work through each action, branch, and trigger:
Enrollment Triggers
The entry point for every contact
What object type does this workflow operate on? What properties are referenced in criteria? Are any forms referenced as submission triggers? Are any list memberships used as criteria?
Actions
Every step the workflow performs
Which marketing emails are sent? Which properties are updated and what values are set? Are there task creation actions with specific owners? Do any actions reference connected integrations (Slack, Salesforce)?
Branches, Suppression & Goals
Logic that controls flow and exit
What properties or behaviors are evaluated at each if/then split? Do branches check list membership or email engagement? Which lists are used for suppression? What conditions define the workflow goal?
Step 2: Audit the Target Portal
With your dependency inventory in hand, check the target portal for each item:
- Properties: Does each referenced property exist with the same internal name and field type? Are dropdown options identical?
- Lists: Do equivalent lists exist? If the source uses an active list filtering on “Lead Score > 50,” does the target portal have a lead scoring model and an equivalent list?
- Forms: Are the required forms available? Do they collect the same fields?
- Emails: Do the marketing emails exist in the target? If not, they need to be created first.
- Pipelines: For deal-based workflows, do the pipeline stages match?
Step 3: Create Missing Dependencies
Build everything that is missing in the target portal before attempting to recreate the workflow. Work from the bottom of the dependency tree upward:
Properties First
They have no dependencies of their own. Create all custom properties with matching internal names, field types, and option values.
Lists Next
They depend on properties. Recreate active lists with equivalent filter criteria that reference the properties you just created.
Forms and Emails
They depend on properties and may reference lists. Build these after the foundational objects are in place.
The Workflow Last
It depends on everything above. Only build the workflow after all its dependencies exist in the target portal.
This bottom-up order prevents circular reference issues and ensures every object exists before it is referenced.
Common Errors in Cross-Portal Workflow Cloning
Experienced HubSpot administrators encounter these errors repeatedly when cloning across portals.
Property Not Found
The workflow references a custom property that does not exist in the target portal. Fix: Create the property with the exact same internal name, field type, and options. Always verify the internal name, not just the display label.
Branch Evaluates Incorrectly
An if/then branch sends all contacts down the wrong path. Fix: Compare dropdown options between portals. Even capitalization differences ("Technology" vs. "technology") cause branch failures.
Email Not Found
The send-email action references a nonexistent email in the target. HubSpot blocks activation until resolved. Fix: Create emails in the target first. See our email template transfer guide.
Suppression List Not Applied
Contacts who should be suppressed (customers, competitors) are being enrolled. Fix: Create an equivalent suppression list in the target portal and configure it in workflow settings.
The workflow is active but has zero enrollments. This often occurs when the enrollment trigger references a form that exists but has not received any submissions in the target portal, or when trigger criteria are so specific that no contacts match. Verify that enrollment criteria match the data in the target portal by creating a test contact that explicitly meets all criteria.
Testing Cloned Workflows: A Framework
Testing is not optional for cross-portal clones. The testing framework below ensures your cloned workflow behaves identically to the source.
Pre-Activation Testing
Before turning the workflow on, validate every component:
- ✓All enrollment trigger criteria reference valid properties and values
- ✓Every email action points to a published marketing email
- ✓All if/then branches reference valid properties with correct operators
- ✓Delay actions have the correct type (calendar vs. business days)
- ✓Suppression lists are configured and populated
- ✓Goal criteria reference valid properties
- ✓Re-enrollment rules match the source configuration
- ✓Internal notification recipients are valid users in the target portal
Controlled Enrollment Testing
Create 5-10 test contacts designed to exercise different workflow paths:
| Test Contact | Purpose | Expected Behavior |
|---|---|---|
| Path A contact | Meets primary branch criteria | Follows the main automation path |
| Path B contact | Meets secondary branch criteria | Routes through alternate branch |
| Suppressed contact | Matches suppression list | Should NOT be enrolled |
| Goal-met contact | Already meets goal criteria | Should exit workflow upon reaching goal |
| Re-enrollment contact | Triggers re-enrollment conditions | Should re-enter if configured |
Manually enroll each test contact and monitor their progression through the workflow over 24-48 hours.
Validation Checklist
After test contacts complete the workflow, verify:
- ✓Each contact followed the expected path
- ✓Emails were sent at the correct intervals
- ✓Property values were updated correctly
- ✓Tasks were created with correct assignments
- ✓Suppressed contacts were not enrolled
- ✓Goal-met contacts were removed appropriately
- ✓Re-enrollment fired correctly for qualifying contacts
Use our comprehensive workflow migration checklist for a more detailed validation framework.
How Jetstack Bridges the Cross-Portal Gap
Jetstack was designed to make cross-portal workflow cloning as close to the same-portal experience as possible.
Automated Dependency Detection
Jetstack automatically scans for every dependency and presents a complete inventory — properties, lists, forms, emails, pipelines, and connected integrations. No manual documentation required.
Smart Matching
Dependencies are matched between source and target by name, type, and configuration rather than by internal ID. A lead_score property is recognized as equivalent regardless of differing IDs.
Gap Resolution
When a dependency is missing in the target, Jetstack offers options: auto-create the missing asset, map to an existing equivalent, or skip the action with a behavior warning.
One-Click Deploy
After dependency resolution, the workflow deploys to the target portal with all references properly mapped. Created in draft state for final review before activation.
Explore the full suite of asset management tools in Jetstack’s Marketplace, or see how implementation services can handle complex cross-portal deployments for you.
When to Clone Within vs. Across Portals
Choosing the right approach depends on what you are trying to accomplish.
Clone Within When...
Same portal, different use case
You need a variation for a different segment, you are A/B testing configurations, you want to archive a working version before major changes, or you are creating seasonal versions of an evergreen workflow.
Clone Across Portals When...
Different account, same automation
A proven workflow needs to run in a different business unit's account, you are deploying agency playbooks to client portals, you are migrating workflows as part of a portal consolidation, a franchise needs standardized automation, or you are promoting from sandbox to production.
If the target portal has a significantly different data model, the workflow is outdated, the target audience has fundamentally different characteristics, or the workflow depends on unavailable integrations — starting from scratch may be the better path. Our workflow audit checklist can help determine whether a workflow is worth cloning.
Frequently Asked Questions
Can I clone a workflow from HubSpot Free to HubSpot Professional?
No. Cloning between portals is not a native feature at any subscription tier. Additionally, HubSpot Free has extremely limited workflow capabilities, so most Professional-tier workflows would reference features that do not exist in a Free account.
Does cloning a workflow within the same portal duplicate the enrolled contacts?
No. A cloned workflow starts with zero enrolled contacts. It is created in a draft (off) state. Contacts will only enter the cloned workflow once you activate it and they meet the enrollment criteria.
If I clone a workflow and then change the original, does the clone update too?
No. Once cloned, the two workflows are entirely independent. Changes to the original do not propagate to the clone, and vice versa. They share no ongoing link.
Can I clone a workflow between a sandbox and production portal?
HubSpot sandboxes support syncing certain assets with their parent portal, but this is a sync mechanism specific to the sandbox-production relationship, not a general cloning feature. For moving workflows between unrelated portals, you need manual recreation or tooling like Jetstack.
How do I handle workflows with custom code actions when cloning across portals?
Custom code actions (available in Data Hub Professional and Enterprise) are embedded in the workflow but may reference portal-specific API keys, external endpoints, or data structures. When cloning across portals, review each custom code block individually. Update API keys, endpoint URLs, and any hardcoded portal references. Test the code block independently before activating the workflow.
What is the maximum number of actions a workflow can have for reliable cross-portal cloning?
There is no hard limit imposed by HubSpot on workflow action count. However, workflows with more than 50 actions and multiple nested branches become significantly harder to clone manually. The risk of human error increases with complexity. For workflows of this scale, automated tooling provides more reliable results than manual recreation.
Will Jetstack work with workflows in any HubSpot subscription tier?
Jetstack works with any HubSpot portal that has workflow access. The minimum HubSpot tier for workflows is Professional. Some workflow features like custom code actions and certain triggers are only available on Enterprise tier. Jetstack will flag any tier-dependent features that cannot be replicated in a lower-tier target portal.
Need to clone workflows across HubSpot portals without the headaches? Contact our team to see Jetstack in action, or explore our Marketplace for ready-to-deploy workflow packages.