How Deployment Works

Deployment takes imported assets from your JetStack AI library and recreates them in a target HubSpot portal. Rather than a simple copy, the deploy engine rewrites every internal reference so assets work correctly in the destination portal — different IDs, different owners, different pipelines.

This page explains the technical mechanics behind the deployment process. For step-by-step instructions, see Selecting Assets to Deploy.

The Deploy Pipeline

When you click Implement, the deployment runs through several phases in order:

1. Analysis — Scans all selected assets and builds a dependency graph. Identifies which assets depend on which other assets.
2. Pre-deploy — Creates any custom objects required by the selected assets. Custom objects must exist before any asset that references them can be deployed. See Custom Object Handling for details.
3. Depth-first deployment — Traverses the dependency graph and deploys assets starting from the leaves (assets with no dependencies) and working inward. This guarantees that every dependency exists in the target portal before any asset that references it is created.
4. Image upload — Uploads cached images to the target portal’s file manager and rewrites URLs throughout all deployed content. See Image & File Handling.
5. Completion — Records final status for every asset. Each asset is marked as succeeded, failed, or skipped.

Depth-First Dependency Resolution

Assets in HubSpot reference each other constantly. A workflow might enroll contacts from a specific list. A page uses a particular template. An email references a form. These references are stored as numeric IDs that differ between every HubSpot portal.

JetStack AI uses depth-first traversal to ensure the correct deploy order:

• The engine builds a directed acyclic graph (DAG) of all selected assets and their dependencies.
• It walks the graph depth-first, deploying leaf nodes first.
• As each asset is created in the target portal, its new ID is recorded in a remapping table.
• When a dependent asset is deployed, the engine substitutes all source IDs with the corresponding target IDs from the remap table.

Example: If you deploy a landing page that uses Template A and contains Form B, the engine deploys Template A first, then Form B, then the landing page — injecting the new template ID and form ID into the page configuration.

If a circular dependency is detected (rare, but possible with certain workflow configurations), the engine gracefully skips the cycle and logs a warning rather than entering an infinite loop.

The ID Remapping Engine

The remapping engine is the core of deployment. Every reference that is portal-specific gets rewritten. This includes:

Reference Type	Example
Asset IDs	Form IDs in page modules, list IDs in workflow enrollment, template IDs in pages
Property names	Custom properties referenced in workflow filters, list criteria, form fields
Pipeline stage IDs	Deal stages in workflow actions, ticket stages in automation
Owner IDs	Assigned owners in workflow actions, rotation steps, default values
Team IDs	Team-based routing in workflows and forms
Subscription types	Email subscription preferences in marketing emails
Lifecycle stages	Custom lifecycle stage values in workflow actions and list filters
Association labels	Custom association labels between object types
Blog authors	Author references in blog post metadata
HubDB row IDs	Row references in HubDB-powered pages and modules

When a mapping is not found for a given reference, the engine uses the source value as a fallback and records a warning in the skippedMappings log. This means the asset is still created, but that specific reference may not work correctly until manually updated. See Property & Asset Mapping for how to configure mappings before deployment.

Duplicate Detection

Before creating any asset, the deploy engine checks whether an asset with the same name already exists in the target portal. This prevents accidental duplicates when deploying to a portal that already has some of the assets.

• Match found: The engine records the existing asset’s ID in the remap table and skips creation. Downstream assets that reference this asset will use the existing ID.
• No match: The engine creates the asset as a new entry.

Matching is done by name (case-insensitive for most asset types). This means if your target portal has a workflow called “Lead Nurture Sequence” and your library contains one with the same name, the existing workflow is reused rather than duplicated.

What Gets Created

Deployment creates new assets in the target HubSpot portal. Specifically:

• CRM assets — Properties, pipelines, pipeline stages, custom objects, association labels
• Marketing assets — Emails, forms, lists, workflows
• CMS assets — Pages, blog posts, templates, modules, HubDB tables
• Files — Images and documents uploaded to the portal’s file manager

All assets are created in a draft or inactive state where applicable. Workflows are deployed as inactive. Emails are created as drafts. Blog posts are not published. This gives you the opportunity to review everything before going live.

Pre-Deploy Phase

Custom objects receive special treatment because they define entirely new object types in the CRM. Many other assets — properties, workflows, lists — may reference custom objects, so they must exist first.

During pre-deploy:

1. JetStack AI identifies all custom object schemas referenced by the selected assets.
2. For each custom object, it checks the target portal for an existing match (by name, singular label, or plural label).
3. If no match is found, the full schema is created including properties, associations, and display settings.
4. The object type ID mapping is recorded for use during the main deployment phase.

See Custom Object Handling for the complete details on schema preservation and property validation.

Tracking Progress

During deployment, the activity detail page shows real-time progress:

• Total assets selected for deployment
• Completed count (successfully created)
• Failed count (with per-asset error details)
• Skipped count (duplicates or circular dependencies)

Each asset’s final status is recorded in your Activity history, where you can review errors, retry failed assets, or investigate skipped mappings.