When you import a workflow, form, list, report, or lead score, that asset often relies on other HubSpot records to work: custom properties, property groups, lists, forms, or emails. HubCreate scans the asset you selected, shows those dependencies, and can import them into your library in the same run.
That matters at deploy time. HubSpot IDs differ between portals. If the dependency is in HubCreate, deployment can recreate it in the target account and rewrite the parent asset so it points at the new IDs instead of the source portal’s.
When HubCreate checks
After you finish the Import Assets wizard and confirm your selection, HubCreate loads the full configuration for each selected asset and scans it. If it finds dependencies, import pauses and a Dependencies Detected modal lists them, grouped under the parent asset they belong to.
Every dependency is checked by default. You can uncheck items you do not want, then choose:
If nothing extra is found, the modal does not appear and import continues as usual.
What HubCreate checks for
The scan depends on the asset type:
Workflows
Forms
Custom contact properties used as form fields.
Lists
Reports *Chrome Extension required
Custom CRM properties used as metrics, dimensions, filters, sorts, columns, and in Advanced Builder joins and filters. HubCreate skips HubSpot standard fields and reporting-only fields such as Record ID.
Lead Scores *Chrome Extension required
Properties the score writes to, custom properties used in fit and intent rules (including associated-object rules), and custom property groups when they are referenced.
Dashboards *Chrome Extension required
A dashboard does not produce property checkboxes of its own. If you import a dashboard, HubCreate automatically includes the Report widgets on that board in the same import. Those reports then go through the report scan above, and HubCreate stores the dashboard-to-report links for later deployment.
What is not treated as a dependency
hs_ prefix. Those already exist in every portal.How dependencies are imported
Those links are what let a later deployment create the supporting records first and rewrite IDs in the parent so lists, forms, emails, and properties still match in the destination portal.
Related guides