Deployment Phase

Deployment is the final phase of a project. The generated assets get pushed to your destination HubSpot portal, internal IDs are wired together, and the implementation goes live. This page covers how the split-deploy mechanism works, what to expect during a deploy, and how to recover from failures.

The Two-Path Deploy

HubSpot exposes two surfaces for creating assets, and not every asset type is available on both. JetStack AI routes each asset to the surface that actually supports it:

Path	Surface	Asset types it handles
API path	Public HubSpot OAuth API	Properties, property groups, pipelines, lifecycle stages, association labels, custom objects, workflows, lists, forms, marketing emails
Extension path	Chrome extension via authenticated HubSpot session	Dashboards, reports, snippets, playbooks, goal templates, lead scores, CRM cards, preview views

The two paths exist because HubSpot’s public API does not currently expose endpoints for the “Extension path” asset types — they live behind authenticated session cookies that only an in-portal browser session has access to. The Chrome extension acts as a proxy that uses your active HubSpot login to create them.

This is the same mechanism the extension uses for premium audit data points and extension-exclusive imports. The difference is that for Projects, it pushes assets out rather than reading them in.

Reviewing the Deploy Plan

Open the Deployment tab in the project workspace. You will see:

• The destination portal — confirm this is correct before starting; switching it now re-validates the plan against the new portal’s existing configuration
• API-deployable group — the assets that will deploy via the public API, in dependency order
• Extension-deployable group — the assets that require the Chrome extension, in dependency order
• Manual group (if any) — assets that cannot be created automatically on either path; these are surfaced with instructions for one-time manual setup
• Total counts for each group

Each asset shows its current deployable state — ready, error, or blocked (if an upstream dependency failed). Click any asset to open the same detail panel as the Assets tab and review or edit its spec one more time before deploying.

Running the API Path

Click Start Deployment. The API path runs first because most extension-path assets reference data-model assets (properties, custom objects, pipelines) that have to exist first.

What happens during the API path:

1. Assets are grouped by type and created in dependency order — property groups before properties, properties before workflows that reference them, pipelines before workflows that move deals between stages, and so on.
2. As each asset is created in HubSpot, any later asset that referenced it has its reference updated automatically. You do not need to manage IDs or relationships by hand.
3. The Assets tab updates the status of each item to Deployed as it lands. You can leave the page; the deploy continues in the background.

If a single asset fails to deploy, the failure does not halt the rest of the deploy:

• The failure is logged with the HubSpot error message
• Any downstream assets that depend on the failed one are marked blocked rather than attempted, because there is no point creating a workflow that references a non-existent property
• Everything else continues normally

When the API path finishes, the Deployment tab shows a summary: successes, failures, blocked. You can review failures, edit the affected specs in the Assets tab, and re-run just those (see Retrying After Failures below).

Running the Extension Path

Once the API path completes, the Deployment tab prompts you to launch the extension path. To run it:

1. Open the Chrome extension on the destination HubSpot portal (the one you selected in the project’s settings). The extension auto-detects that this portal has a pending deploy and surfaces a banner.
2. Click the banner. The deploy plan for the extension path appears in the extension sidebar, with the same asset list grouped by type.
3. Click Run Deploy. The extension creates each asset using your active HubSpot session.
4. The dashboard’s Assets tab stays in sync as each asset lands, so you can monitor progress from either surface.

Same portal, same session

The extension must be open on the destination portal that the project is deploying to — not a different portal you happen to be in. The extension uses the currently-active portal’s session cookies, so if you are on Portal A but deploying to Portal B, the deploy will fail with authentication errors.

What If the Extension Path Is Long?

For projects with many dashboards, reports, and other extension-path assets, the extension deploy can take several minutes. You can:

• Leave the extension open — it runs in the background and you can keep browsing HubSpot
• Close and reopen later — the deploy state is durable; opening the extension on the destination portal resumes where it left off
• Pause and resume — click the pause icon in the extension’s deploy bar to halt after the current asset finishes

The dashboard’s Assets tab stays in sync throughout, so you can monitor progress from the web side or the extension side.

Manual Setup Assets

A small number of asset types cannot be created on either path because HubSpot does not currently support programmatic creation. Examples include certain user permission sets and some account-level settings. These assets appear in the Manual group in the deploy plan with step-by-step instructions for setting them up by hand.

The project tracks the manual assets but does not block deployment on them — you can deploy everything else, set up the manual items at your own pace, and mark them complete in the asset detail panel.

Retrying After Failures

Failed assets stay in the project until you resolve them. To retry:

1. Open the failed asset in the Assets tab. The detail panel shows the HubSpot error message that caused the failure.
2. Decide whether to edit the spec (fix the cause of the error), regenerate (ask Jetty to produce a new spec), or skip (mark the asset as deferred — useful if the failure is portal-specific and you do not want to block deployment).
3. Return to the Deployment tab. Failed and edited assets are surfaced for redeploy.
4. Click Retry Failed. Only the affected assets — and any downstream ones that were previously blocked by them — are re-run.

Common failure causes and resolutions:

Failure	Cause	Resolution
Reserved property name	Spec used a hs_* prefix HubSpot reserves	Edit the property name in the Assets tab
Pipeline stage probability sum != 1.0	Generated probabilities did not normalise	Regenerate the pipeline or adjust stage probabilities manually
Property type mismatch on existing field	The destination portal already has a property with the same internal name but a different type	Either rename the project property or delete the destination’s conflicting property
Workflow references unknown list	Upstream list failed to deploy	Resolve the list failure first, then retry the workflow
Internal HubSpot error 5xx	Transient HubSpot issue	Wait a minute and retry; cascading retries are automatic

What’s Live After Deploy?

When the deploy completes (API path plus extension path), every successfully-deployed asset is live in the destination portal. Properties show up in records, pipelines are usable, workflows are running (subject to their enrollment criteria), forms can be embedded, dashboards are visible.

A few things to know about the post-deploy state:

• Workflows start enrolling records that match their criteria as soon as they are created. If you do not want active enrollment yet, edit the workflow in HubSpot and turn it off before any records meet the criteria.
• Lists begin populating based on their filter logic. Dynamic lists evaluate against the existing record set immediately.
• Lifecycle stages are applied to existing contacts retroactively only if you explicitly opted in during the blueprint phase; otherwise, only new records enter the stages.
• Dashboards and reports are created in the deploying user’s dashboard scope. Move them to a shared dashboard if needed.

Re-Deploying or Updating

The project remembers what is already deployed. If you later edit an asset and want to push the change to HubSpot, the next deploy updates the existing asset in place rather than creating a duplicate — on both the API path and the extension path.

This means you can keep iterating on a project after the first deployment without creating clutter. The Assets tab shows whether each asset is Deployed, Deployed (out of sync) (you have edited the spec since the last deploy), or Ready. Out-of-sync assets are highlighted in the Deployment tab for redeploy.

Next Steps

• Troubleshooting & Gotchas — Known limits and recovery flows
• Asset Generation — Editing assets before redeploy
• Extension Overview — The Chrome extension’s broader role in the platform