Deployment & Verification

Apply is the step where an authorized Release changes the portal. Assets deploy in dependency order across two paths, every asset records its verbatim HubSpot outcome, and verification then reads the portal back to confirm what actually landed. When something goes wrong, the unit of recovery is a single asset — repair, not restart.

The Two-Path Deploy

HubSpot exposes two surfaces for creating assets, and not every asset type is available on both. Each asset routes 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 expose endpoints for the extension-path types — they live behind authenticated session cookies that only an in-portal browser session has. The Chrome extension acts as a bridge that uses your active HubSpot login to create them. It is the same mechanism the extension uses for the browser lane of the portal scan, running in the write direction.

The API path runs first, because extension-path assets usually reference data-model assets that must exist before they do. As each asset is created, later assets that reference it have their references wired automatically — you never manage HubSpot IDs by hand.

Same portal, same session

The extension must be open on the portal the Release is applying to — the bound portal for the active mode. If you are in a different portal, the extension path fails with authentication errors rather than deploying into the wrong place.

Sandbox and Production Modes

A Release applies to one mode — the sandbox portal or the production portal, whichever the project has bound and you have selected. The mode is unmissable throughout the Delivery tab, and production carries stronger confirmations by design. If the project only has one portal bound, only that mode exists; the workspace never quietly substitutes one portal for another.

Per-Asset Outcome Rows

The row, not the run, is the unit of delivery. In the Release’s Delivery tab, every asset has its own row carrying:

• Its deploy state — pending, applying, applied, failed, or blocked (an upstream dependency failed, so this asset was not attempted)
• The verbatim outcome from HubSpot — the actual response, including the real error message on failure, not a paraphrase
• The HubSpot ID it now maps to, once created
• Its verification result and evidence

A single failed asset does not halt the Release. Dependents of the failure are marked blocked instead of attempted; everything independent continues.

Verification

After apply, verification reads the portal back and compares each created asset against its spec:

• Only canonically authored fields are compared — the fields the spec actually set. HubSpot adds server-side defaults and metadata to everything it creates; those are not treated as drift.
• The result is labeled with its evidence strength. A field-by-field read-back is stronger evidence than an existence check, and the row says which it got — verification never overstates its confidence.
• An asset that exists but does not match its spec is surfaced as such, with the mismatched fields shown.

Repair, Not Restart

Any asset that failed to apply or verified wrong gets Repair:

1. Open the failed row and read the verbatim HubSpot outcome.
2. Trigger Repair. The failure is classified — spec problem, portal conflict, transient error — and routed to the right fix: a spec correction, a conflict resolution, or a straight retry.
3. The single asset is redeployed and re-verified. Nothing else in the Release is touched, and previously blocked dependents unblock once the repair lands.

Common failure patterns:

Failure	Cause	Resolution
Reserved property name	Spec used a prefix HubSpot reserves (hs_*)	Repair with a renamed property
Property type mismatch on existing field	The portal already has a property with the same internal name but a different type	Rename the project’s property, or resolve the conflict in the portal
Workflow references unknown list	An upstream list failed to apply	Repair the list first; the workflow unblocks
Internal HubSpot error 5xx	Transient HubSpot issue	Repair retries cleanly

Updates and Redeploys

The project remembers the HubSpot ID behind every applied asset. When a later Release (or a repair) changes an asset that already exists in the portal, the apply updates it in place rather than creating a duplicate — on both paths. If the portal-side copy was deleted externally, verification catches the missing asset and repair recreates it with a fresh link.

What’s Live After Apply

Successfully applied assets are live in the portal immediately, so know the defaults:

• Workflows can start enrolling records that meet their criteria as soon as they exist — check enrollment settings before applying to production if that matters.
• Dynamic lists evaluate against the existing record set immediately.
• Dashboards, reports, and CRM cards are created in the applying user’s scope; share them in HubSpot if the client team needs them.

Every operation the project has ever run against the portal — applies, repairs, rescans — is in the project’s Deploy logs, permanently.

Next Steps

• Releases — The lifecycle around apply
• Troubleshooting & Gotchas — Deploy-time recovery flows
• Extension Overview — The Chrome extension’s broader role