Skip to content

Dependencies & Auto-Import

HubSpot assets frequently reference other assets. A workflow might send an email, enroll contacts from a list, and update a pipeline stage. Each of those references is a dependency — an asset that must exist for the parent asset to function correctly.

JetStack AI automatically detects these dependencies during import and fetches them alongside your explicitly selected assets. This page explains how dependency detection works, provides the full dependency map, and covers edge cases.

When you select an asset for import, JetStack AI’s specialized parser for that asset type scans its configuration for references to other assets. Each discovered reference becomes a dependency that is also imported.

This process is recursive. If a dependency has its own dependencies, those are discovered and imported too. The recursion continues until all dependencies at every level have been resolved.

For example, if you select a single workflow:

  1. JetStack AI parses the workflow and finds it references List A and Email B
  2. List A is imported — its parser finds it references Form C
  3. Form C is imported — its parser finds it references a redirect page (Page D)
  4. Email B is imported — its parser finds it references Template E
  5. Template E is imported — no further dependencies
  6. Page D is imported — its parser finds it references Template F
  7. Template F is imported — no further dependencies
  8. The workflow is imported last, with all dependencies already in place

You selected 1 asset but ended up with 7 assets in your library. This is expected and intentional.

Your Asset Library distinguishes between two categories:

  • Explicit assets — assets you directly selected in the import wizard
  • Dependency assets — assets that were automatically imported because another asset references them

This distinction helps you understand why assets appear in your library that you did not manually select. Both types are fully functional and can be deployed — the label is purely informational.

The following table shows what each asset type can depend on. During import, JetStack AI scans for all of these reference types.

Workflows have the broadest dependency footprint:

Dependency TypeWhere Found
ListsEnrollment criteria, suppression lists, branch conditions
FormsForm submission triggers, enrollment criteria
EmailsSend-email actions, A/B email actions
Other WorkflowsEnroll-in-workflow actions, goal criteria
PipelinesSet-deal-stage actions, pipeline-based enrollment
PropertiesSet-property actions, branch conditions, enrollment criteria
OwnersSet-owner actions, rotation actions
Subscription TypesEmail send actions
Lifecycle StagesSet-lifecycle-stage actions
Custom ObjectsObject-based workflow enrollment and actions
Dependency TypeWhere Found
Nested Lists”Is member of list” filter criteria
Forms”Has filled out form” filter criteria
Emails”Has received/opened/clicked email” filter criteria
Workflows”Is enrolled in workflow” filter criteria
Pages”Has visited page” filter criteria
Owners”Contact owner” filter criteria
Subscription TypesSubscription-based filter criteria
Lifecycle StagesLifecycle-based filter criteria
PipelinesDeal/ticket pipeline filter criteria
Dependency TypeWhere Found
WorkflowsForm submission workflows, follow-up workflows
PagesRedirect URL after submission
PropertiesForm fields mapped to contact/company properties
OwnersDefault owner assignment
TeamsTeam-based routing on submission
Lifecycle StagesLifecycle stage set on submission
Subscription TypesConsent/subscription fields
Dependency TypeWhere Found
TemplatesEmail template reference
BlogsBlog RSS feed configuration (for blog emails)
WorkflowsLinked workflow references in smart content
ListsSmart content list-based rules
Subscription TypesEmail subscription type assignment
Dependency TypeWhere Found
TemplatesPage template reference
BlogsBlog listing references
FormsEmbedded form modules
HubDB TablesDynamic content data sources
Template ModulesCustom module instances on the page
Dependency TypeWhere Found
Parent TemplatesTemplate inheritance (extends)
ModulesModule references in template source
HubDB TablesHubDB data lookups in HubL code
FormsDefault form references in template configuration
Dependency TypeWhere Found
WorkflowsStage-entry automation workflows
EmailsStage-entry automated emails
OwnersDefault stage owners
PropertiesRequired properties per stage
Dependency TypeWhere Found
BlogsParent blog container
TemplatesPost template reference
Blog AuthorsPost author reference
Dependency TypeWhere Found
Other HubDB TablesForeign key column references

The most common question after an import is: “I only selected 5 assets, but 20 showed up in my library. Why?”

The answer is dependency auto-import. Every asset that your selected assets reference — directly or transitively — is imported to ensure a complete, deployable set. Without these dependencies, deployment would fail because the destination portal would be missing required referenced assets.

You can identify which assets were auto-imported by checking the asset’s import type in the library. Dependency assets are labeled accordingly.

In rare cases, two assets may reference each other. Common examples:

  • A workflow adds contacts to a list, and that list’s filter criteria include “is enrolled in” that same workflow
  • Two workflows reference each other through enroll-in-workflow actions

JetStack AI detects circular dependencies by tracking the processing path during depth-first traversal. When a cycle is detected:

  1. The traversal stops recursing along the circular path
  2. The asset that would create the cycle is imported with a partial result — its own data is stored, but the back-reference is flagged for deferred resolution
  3. All other non-circular dependencies continue importing normally
  4. The circular reference is resolved during deployment using a two-pass approach

Circular dependencies do not cause import failures. They are handled gracefully and logged for visibility.

  • Select top-level assets only. Do not manually select assets you think might be dependencies — JetStack AI discovers them automatically. Selecting them explicitly just creates duplicate work.
  • Review the import summary. Before confirming, check the grouped summary in Step 3 of the wizard. If unexpected asset types appear, it is because your selected assets depend on them.
  • Start small for complex portals. If you are importing from a portal with hundreds of interconnected assets, start with a small set to understand the dependency footprint before importing everything.
  • Check the Activity Log. After import, the Activity Log shows every asset that was processed, including which were explicit selections and which were auto-detected dependencies.