Logo Logo Docs

HubCreate documentation

Find all the guides and resources you need to get up and running with HubCreate.
Sign In

Asset Dependencies

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:

  • Import Selected Dependencies — import the checked items, then import the assets you originally selected.
  • Skip Dependencies — import only the assets you selected. You will need to recreate or wire up the missing pieces in HubSpot yourself.

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

  • Custom properties used in enrollment, filters, association branches, and set-property actions — including properties on associated objects, not only the workflow’s primary object.
  • Custom property groups those properties belong to (when the group is not a HubSpot default group).
  • Forms referenced by form-submission enrollment.
  • Marketing emails sent by the workflow (to the enrolled contact or as an internal email).
  • Lists used in enrollment or actions (for example in-list filters and add-to-list steps).

Forms

Custom contact properties used as form fields.

Lists

  • Custom properties on the list’s object, including properties on associated objects in the filter.
  • Other lists referenced by in-list or association in-list filters. The list you are importing is not treated as a dependency of itself.

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

  • HubSpot standard properties — native fields such as email or first name, HubSpot-defined properties, and anything with an hs_ prefix. Those already exist in every portal.
  • Default property groups — HubSpot’s built-in groups are not imported.
  • Records HubCreate cannot fetch — if a property or group returns not found or forbidden, it is skipped rather than blocking the import.
  • Emails, pipelines, landing pages, HubDB tables, and custom objects as the selected parent — these types are imported as-is. They are not scanned for nested dependencies the way workflows, forms, lists, reports, and lead scores are.

How dependencies are imported

  1. HubCreate looks up each selected dependency in the source HubSpot account and stores a copy in your Asset Library — properties (with their object type and group), property groups, lists, forms, and emails.
  2. The assets you originally selected are imported next.
  3. Parent assets are linked to the dependencies imported in that batch. Duplicate dependencies (the same property used by two workflows, for example) are created once.

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