If you manage more than one HubSpot portal, you already know the pain. You spent weeks building a sophisticated lead nurture workflow in your primary account, and now the sales team in a second region needs the same thing. You open HubSpot, search for a “copy to another portal” button, and realize it does not exist.
HubSpot does not offer a native way to copy workflows between portals. This limitation affects agencies managing client accounts, franchises scaling proven playbooks, and enterprises consolidating after acquisitions. The good news: there are reliable ways to get it done, and this guide walks through every option, pitfall, and best practice.
Why You Would Need to Copy Workflows Between Portals
Before diving into the how, it helps to understand the common scenarios that drive this need. Copying workflows between portals is not just a convenience feature. For many organizations, it is a strategic requirement.
Scaling Across Regions
Companies operating in multiple markets maintain separate portals per region. A workflow that qualifies and routes leads in North America should work identically in EMEA, adjusted for time zones and language. Rebuilding from scratch wastes hours and introduces inconsistencies.
Franchise & White-Label Models
Franchise operations and white-label SaaS providers deploy the same automation logic across dozens of client portals. When a franchisor develops a best-practice onboarding sequence, every franchisee portal should receive it without deviation.
Agency Playbook Deployment
Agencies develop proven workflow templates for lead scoring, lifecycle management, and deal rotation. Without a copy mechanism, every engagement starts with manual recreation. See our agency guide to replicating HubSpot automation.
Post-Acquisition Consolidation
When two companies merge, their HubSpot portals often need to be consolidated. The surviving portal needs the best workflows from both accounts. This process is covered in our portal consolidation guide.
What HubSpot Does and Does Not Allow Natively
Understanding the native constraints is essential before choosing an approach.
What You Can Do Within a Single Portal
HubSpot allows you to clone a workflow inside the same portal. This creates a copy with the same actions, delays, and branches. It is a useful starting point for variations on a theme, but the clone stays within the same account. We compare same-portal and cross-portal cloning in detail in our cloning comparison post.
What You Cannot Do Across Portals
There is no native export-import for workflows. You cannot download a workflow as a file and upload it to another portal. The HubSpot API exposes workflow definitions through the Automation API, but the response includes internal object IDs that are specific to the source portal. Lists, forms, properties, and enrollment triggers all reference portal-specific identifiers that will not resolve in a different account.
A raw API export will fail if imported as-is into a different portal. Every internal ID — lists, forms, properties, owners, emails — must be mapped to its equivalent in the target account.
The Sandbox Complication
HubSpot’s sandbox environment does allow syncing certain assets from production, but sandboxes are designed for testing, not for transferring assets to entirely separate portals. With the legacy sandbox sunset in March 2026, even this limited pathway is changing.
The Manual Recreation Approach
For teams with a small number of simple workflows, manual recreation may be the most straightforward path. Here is how to do it systematically.
Document the Source Workflow
Open the workflow in the source portal and create a detailed record of every component: trigger type, enrollment triggers (including AND/OR logic), re-enrollment settings, actions in sequence, goal criteria, and suppression lists.
Verify Dependencies in the Target Portal
Confirm that every dependency exists in the destination portal — custom properties, active/static lists, forms, email templates, pipelines, and deal stages.
Rebuild in the Target Portal
With dependencies verified, recreate the workflow action by action. Pay close attention to branch logic, delay types, notification recipients, and property values.
Test Before Activating
Enroll a small batch of test contacts to validate the workflow end-to-end. Check that each branch fires correctly, emails send to the right recipients, and properties update as expected.
Missing dependencies are the number one cause of broken workflow migrations. Our workflow dependencies guide covers this topic exhaustively.
When rebuilding, match delay types carefully. "Calendar days" and "business days" behave very differently, especially across time zones. A workflow designed for EST will fire at unexpected hours in a portal configured for GMT.
Using the HubSpot API for Cross-Portal Copies
For technical teams comfortable with API integrations, the HubSpot Automation API provides programmatic access to workflow definitions.
Extracting the Workflow Definition
The /automation/v4/flows endpoint returns the JSON representation of a workflow, including all actions, branches, and enrollment criteria. This definition can serve as a blueprint for recreation in another portal.
The ID Translation Problem
The core challenge is that every reference within the workflow uses portal-specific IDs:
| Reference Type | Example | Portal-Specific? | Translation Needed |
|---|---|---|---|
| List IDs | List 42 in Portal A | Yes | Must find/create equivalent list in Portal B |
| Form GUIDs | Globally unique but portal-bound | Yes | Must map to target portal’s form |
| Property internal names | lead_score_v2 | Varies | Must verify existence and field type |
| Owner IDs | HubSpot user IDs | Yes | Must map to target portal’s users |
| Email IDs | Marketing email content IDs | Yes | Must recreate or map email templates |
Building a Translation Layer
Organizations that regularly copy workflows between portals sometimes build middleware that maintains a mapping table between source and target IDs. This approach works but requires ongoing maintenance as new properties, lists, and forms are created.
Building a reliable translation layer typically requires 80-160 hours of development time. Maintaining it against HubSpot API changes adds ongoing cost that many teams underestimate.
How Jetstack Handles Cross-Portal Workflow Copying
Jetstack’s Marketplace offers purpose-built tooling that addresses the cross-portal copy problem without requiring custom API development.
| Capability | Manual Recreation | API Custom Build | Jetstack |
|---|---|---|---|
| Dependency detection | No | Partial | Yes |
| Automatic ID translation | No | Partial | Yes |
| Enrollment trigger preservation | Partial | Partial | Yes |
| Pre-copy validation | No | No | Yes |
| Rollback capability | No | Partial | Yes |
| Setup time | None | Weeks | Minutes |
Dependency Resolution
When you initiate a workflow copy through Jetstack, the system scans the source workflow for every dependency: properties, lists, forms, emails, and pipeline stages. It then checks the target portal for matching assets. Missing dependencies are flagged with clear resolution options: create the missing asset, map it to an existing equivalent, or skip it.
Intelligent ID Translation
Rather than a brittle one-to-one ID map, Jetstack matches assets by name, type, and configuration. A contact property called lead_score in the source portal is matched to lead_score in the target, regardless of differing internal IDs. Ambiguous matches are surfaced for manual confirmation.
Enrollment Trigger Preservation
Enrollment triggers are the most fragile part of a workflow copy. Jetstack rebuilds trigger logic using the target portal’s object schema, preserving the original filter structure while swapping in local references. Re-enrollment rules and suppression criteria carry over intact.
Validation and Dry Run
Before any changes are committed to the target portal, Jetstack generates a validation report showing exactly what will be created, modified, or skipped. You can review the full action sequence and approve or adjust before activation.
For a broader look at tools in this space, see our comparison of tools for copying HubSpot assets.
Common Pitfalls When Copying Workflows
Even with the right approach, there are traps that catch experienced HubSpot administrators.
Forgetting Re-Enrollment Rules
A workflow may look correct but behave differently because re-enrollment settings were not replicated. If the source allows re-enrollment on property change and the copy does not, contacts enter only once — breaking nurture logic that depends on repeated engagement.
Mismatched Property Field Types
A property named "industry" might be a dropdown in one portal and a single-line text in another. The workflow action "set industry to Technology" will fail silently if the target property does not have "Technology" as a valid option.
Time Zone Discrepancies
Workflows with "send during business hours" actions behave differently depending on the portal's time zone setting. A workflow designed for EST will fire at unexpected hours in a portal configured for GMT.
Connected App Dependencies
Some workflows include actions that depend on connected integrations like Slack notifications, Salesforce syncs, or Zoom registration. These integrations are portal-specific and will not transfer.
If the source workflow uses custom-coded actions (Data Hub), the code itself may reference portal-specific API keys, endpoints, or data structures. These actions require separate review and adaptation for each target portal.
Step-by-Step Walkthrough: Copying a Lead Nurture Workflow
Let us walk through a concrete example. You have a five-email lead nurture workflow in Portal A that needs to exist in Portal B.
1. Audit the Source Workflow
Open the workflow in Portal A and note:
- Enrollment trigger: Contact submitted “Demo Request Form” AND lifecycle stage is “Lead”
- Suppression: Contacts in “Customers” list are excluded
- Actions: Five marketing emails sent at 3-day intervals, with an if/then branch after Email 3 based on email engagement
- Goal: Lifecycle stage changes to “MQL”
2. Inventory Dependencies
Create a checklist of everything the workflow references:
- ✓"Demo Request Form" form
- ✓"Lifecycle Stage" property (standard — should exist)
- ✓"Customers" static list
- ✓Five marketing email templates (content, subject lines, sender)
- ✓Email engagement properties for branching (opens, clicks)
Use our workflow migration checklist to ensure nothing is missed.
3. Prepare the Target Portal
In Portal B:
- Create or verify the “Demo Request Form” exists with matching fields
- Confirm the “Customers” list exists or create it with equivalent criteria
- Recreate the five marketing emails (or use Jetstack to copy email templates, covered in our email template transfer guide)
Always create dependencies in order: properties first (no dependencies of their own), then lists (depend on properties), then forms and emails, then the workflow last. This prevents circular reference issues.
4. Rebuild or Deploy the Workflow
Using the manual method, recreate each action in Portal B’s workflow editor. Using Jetstack, initiate a cross-portal copy and resolve any dependency conflicts in the validation step.
5. Test with a Controlled Cohort
Create 5-10 test contacts in Portal B. Manually enroll them and verify:
- ✓Enrollment trigger fires correctly
- ✓Emails send in the right sequence with correct delays
- ✓The if/then branch evaluates engagement data properly
- ✓The goal criteria removes contacts at the right stage
- ✓Suppressed contacts are excluded
6. Activate and Monitor
Turn the workflow on and monitor the first 48-72 hours closely. Check for unexpected enrollment spikes or zero enrollments, email delivery issues, and whether branch path distribution matches expectations.
When to Invest in a Systematic Approach
Manual recreation works for one or two workflows. But if you regularly need to copy automation across portals, the time investment compounds quickly.
- 4-6 hours per complex workflow
- High risk of human error
- No rollback if something breaks
- Costs multiply linearly with scale
- No dependency validation
- Minutes per workflow with Jetstack
- Automated dependency resolution
- Pre-copy validation and rollback
- Costs stay flat at scale
- Full dependency audit trail
Organizations that manage five or more portals, agencies that onboard new clients monthly, and franchises scaling to new locations should evaluate systematic tooling. The upfront investment in a proper copy-and-deploy process pays for itself after the third or fourth migration.
Explore Jetstack’s implementation services for guided workflow deployment, or start with a portal audit to understand exactly what needs to move.
Frequently Asked Questions
Can I copy a workflow from one HubSpot portal to another using native tools?
No. HubSpot does not provide a built-in feature to copy workflows between separate portals. You can clone a workflow within the same portal, but cross-portal copying requires either manual recreation, API-based extraction, or a third-party tool like Jetstack.
What happens to enrollment triggers when I copy a workflow?
Enrollment triggers reference portal-specific objects like forms, lists, and properties. When you copy a workflow to a new portal, each trigger must be remapped to equivalent objects in the target portal. If the referenced form or list does not exist, the trigger will be invalid.
Do I need Data Hub to copy workflows between portals?
Data Hub is not required for copying workflows. However, if your workflows contain custom-coded actions (a feature of Data Hub Professional and Enterprise), those code blocks will need to be reviewed and potentially modified for the target portal.
How long does it take to manually recreate a workflow in another portal?
A simple linear workflow with 5-10 actions can be recreated in 30-60 minutes. Complex workflows with multiple if/then branches, dozens of actions, and several dependencies can take 4-6 hours, including testing. Using Jetstack’s tooling reduces this to minutes.
Will my workflow analytics transfer when I copy?
No. Workflow performance data, including enrollment counts, conversion rates, and historical execution logs, is portal-specific and cannot be transferred. The copied workflow in the target portal starts with a clean analytics slate.
Can I copy workflows between a sandbox and a production portal?
HubSpot sandboxes support limited asset syncing with their parent production portal. However, this mechanism is not designed for copying between unrelated portals. With the legacy sandbox sunset approaching, organizations should evaluate alternative approaches. See our sandbox migration guide for details.
What is the safest way to test a copied workflow before going live?
Create a small set of test contacts that match the enrollment criteria. Manually enroll them and monitor each step. Verify email delivery, branch logic, property updates, and goal criteria. Only activate the workflow for your full database after confirming correct behavior in the test cohort.
Need help copying workflows between HubSpot portals? Contact us to learn how Jetstack can automate the process and eliminate manual recreation.