Skip to content

Deploy Failures

This page covers every common deployment failure you may encounter in JetStack AI. Deployment is when JetStack AI creates assets in a destination HubSpot portal based on what you imported into your Asset Library. Each entry follows a Symptom / Cause / Solution format.

Symptom: Deployment fails with “Duplicate name” or “An asset with this name already exists.”

Cause: HubSpot enforces unique names for certain asset types within a portal. If the destination portal already has an asset with the same name, the API rejects the creation request. This affects:

  • Workflows (unique names per object type)
  • Lists (unique names globally)
  • Pipelines (unique names per pipeline type)
  • Properties (unique internal names per object type)
  • Custom objects (unique names globally)

Solution:

  1. Check the destination portal for existing assets with the same name
  2. Rename or delete the conflicting asset in the destination portal
  3. Alternatively, rename the asset in JetStack AI’s deployment wizard before deploying
  4. For properties, note that the internal name (not the display label) must be unique

Symptom: Deployment fails with “Mapping not found” for a property, pipeline, owner, or other reference.

Cause: During deployment, JetStack AI remaps source portal IDs to destination portal equivalents. This error occurs when:

  • A property referenced by a workflow or list does not exist in the destination portal and was not included in the deployment
  • A pipeline stage referenced by a workflow action was not mapped
  • An owner (user) referenced in an assignment action has no equivalent in the destination portal
  • A list referenced by a workflow enrollment trigger was not deployed or mapped

Solution:

  1. Return to the mapping step in the deployment wizard
  2. Review all unmapped items and provide mappings
  3. For properties: deploy the required properties first, or map to existing destination properties
  4. For owners: map source portal users to destination portal users in the owner mapping step
  5. For pipelines: complete the pipeline mapping to associate source stages with destination stages

Symptom: Deployment slows dramatically or fails with a rate limit error.

Cause: Same as import rate limits — HubSpot enforces 100 requests per 10 seconds. Deployments are more API-intensive than imports because they involve both reading destination state and writing new assets.

Solution:

  1. Wait 30-60 seconds and retry
  2. Deploy smaller batches of assets
  3. Ensure no other operations (imports, audits) are running on the same destination portal
  4. JetStack AI retries automatically with exponential backoff; check the Activity Log for retry status

Symptom: Deployment log shows “Property type mismatch” and the property was created with a modified name.

Cause: A property with the same internal name exists in the destination portal but has a different field type (e.g., number in source, string in destination). HubSpot does not allow changing a property’s type after creation.

Solution:

  1. JetStack AI handles this automatically using a suffix strategy — it creates the property with a modified internal name (e.g., my_property_2) and logs the discrepancy
  2. Review the deployment log to see which properties were renamed
  3. After deployment, decide whether to:
    • Keep the new property and update references in workflows/lists manually
    • Delete the conflicting property in the destination and redeploy
    • Manually reconcile the two properties

Symptom: Deployment fails when creating a pipeline with “Pipeline creation failed.”

Cause: Pipeline creation failures typically result from:

  • The destination portal tier does not support additional pipelines (Free/Starter tiers have pipeline limits)
  • Stage names within the pipeline are not unique
  • The pipeline type (deal, ticket, custom object) is not available on the destination portal’s tier
  • The maximum number of pipelines for the portal tier has been reached

Solution:

  1. Check the destination portal’s HubSpot tier and pipeline limits
  2. Verify that all stage names in the pipeline are unique
  3. For tier-restricted pipeline types, upgrade the destination portal
  4. If the portal has reached its pipeline limit, delete unused pipelines or upgrade the tier

Symptom: Deployment of a page or email fails with “Template not found.”

Cause: Pages and emails reference templates by ID. If the template has not been deployed to the destination portal yet, or if the template deployment failed, the page or email deployment will fail.

Solution:

  1. Deploy the template before deploying pages or emails that reference it
  2. Check the Activity Log to confirm the template deployed successfully
  3. If the template deployment also failed, resolve that failure first (see Templates section below)
  4. JetStack AI deploys assets in dependency order, but if you manually override the order, you may encounter this issue

Symptom: List deployment fails with “Timezone validation error” on a filter using TIME_RANGED operations.

Cause: HubSpot’s list creation API rejects IANA timezone identifiers (e.g., America/New_York) and only accepts legacy timezone strings (e.g., US/Eastern). Additionally, indexReference.referenceType values of MONTH are rejected — only TODAY and NOW are valid.

Solution:

  1. JetStack AI automatically converts IANA timezones to legacy equivalents during deployment
  2. If this error persists, the specific timezone may not have a known legacy mapping
  3. Check the deployment log for the specific timezone value that failed
  4. As a workaround, modify the list filter in the source portal to use a supported timezone and re-import
  5. Contact support if you encounter a timezone that JetStack AI does not handle

Symptom: Deployment fails with “Circular dependency detected” and lists two or more asset names.

Cause: Two or more assets reference each other, creating a loop in the dependency graph. For example:

  • Workflow A enrolls contacts from List B, and List B filters on a property set by Workflow A
  • Email A includes a smart rule referencing List C, and List C filters on email open events for Email A

Solution:

  1. Review the circular dependency chain in the error details
  2. Break the cycle by deploying one asset first without the circular reference
  3. After all assets are deployed, manually update the reference to complete the loop
  4. For workflow-list cycles, deploy the list first (without the workflow-dependent filter), deploy the workflow, then update the list filter

Symptom: Workflow deploys but some actions are skipped or show warnings.

Cause: Workflow deployment issues typically involve:

  • Actions referencing assets that were not included in the deployment (emails, lists, properties)
  • Delay actions with absolute date references that are in the past
  • Custom code actions that reference portal-specific API keys or endpoints
  • Go-to actions pointing to branches that were restructured

Solution:

  1. Include all referenced assets in the deployment, or ensure they already exist in the destination portal
  2. Review the deployment log for specific action warnings
  3. Absolute date references are deployed as-is — update them manually in the destination portal
  4. Custom code actions are deployed as-is — update API keys and endpoints manually

Symptom: List deploys but filter conditions are incomplete or incorrect.

Cause: List deployment issues commonly involve:

  • Filters referencing properties that do not exist in the destination portal
  • IN_LIST filters referencing lists that were not deployed
  • TIME_RANGED filters with timezone or reference type issues (see Timezone Validation Error)
  • Event-based filters referencing form submissions or page views with unmapped IDs

Solution:

  1. Deploy all referenced properties and lists before deploying the parent list
  2. Review filter conditions in the destination portal after deployment
  3. For event-based filters, manually verify that form and page references resolve correctly
  4. JetStack AI remaps IDs automatically where possible; unmapped references are logged in the task details

Symptom: Form deploys but is missing fields or configuration.

Cause: Form deployment uses HubSpot’s v3 API, which does not support all v2 field configurations. Known gaps:

  • Some progressive profiling field queue configurations
  • Certain dependent field visibility rules
  • Legacy field validation formats

Solution:

  1. Review the deployed form in the destination portal
  2. Manually configure progressive profiling and dependent field rules if they were not transferred
  3. Test the form submission in the destination portal to verify all fields work correctly

Symptom: Email deploys but content appears broken or references are missing.

Cause: Email deployment issues include:

  • Template references not resolving (template not deployed first)
  • Image URLs pointing to the source portal’s file manager
  • Smart content rules referencing lists that were not deployed
  • Subscription type IDs not mapping to the destination portal

Solution:

  1. Deploy the email’s template before deploying the email
  2. JetStack AI re-uploads images during deployment; if images are missing, check the deployment log for image upload failures
  3. Map subscription types during the deployment wizard
  4. Review smart content rules after deployment and update list references if needed

Symptom: Template deploys but pages using it show layout errors.

Cause: Template deployment issues include:

  • Custom module references not resolving (modules not deployed first)
  • generated_layouts path not created correctly in the destination file system
  • Template source code using HubL functions with portal-specific references
  • DND (drag-and-drop) area configurations not transferring completely

Solution:

  1. Deploy all custom modules before deploying the template
  2. Deploy pages after templates — the page deployment will reference the newly created template ID
  3. Check the template preview in the destination portal for layout issues
  4. For HubL portal-specific references, update them manually in the destination template

Symptom: Page deploys but displays incorrectly or is missing content.

Cause: Page deployment depends on successful template and module deployment. Issues include:

  • Template not deployed or deployment failed
  • Module content referencing images from the source portal
  • Slug conflicts with existing pages in the destination portal
  • Multi-language variants deploying without proper language group association

Solution:

  1. Verify the template deployed successfully before deploying pages
  2. Check module images in the deployed page
  3. For slug conflicts, update the page slug in the deployment wizard
  4. Multi-language pages are deployed individually; manually associate them in the destination portal

Symptom: HubDB table deploys but is missing rows or has incorrect column types.

Cause: HubDB deployment issues include:

  • Foreign ID columns referencing other HubDB tables that were not deployed
  • Column type mismatches between source and destination
  • Row data containing references to portal-specific records
  • Table not auto-published after deployment

Solution:

  1. Deploy referenced HubDB tables (foreign ID columns) first
  2. Review column definitions in the deployed table
  3. Manually publish the table in the destination portal if it was deployed in draft state
  4. Update foreign ID column values to reference the new table IDs in the destination portal

Symptom: Pipeline deploys but stages are missing or in the wrong order.

Cause: Pipeline deployment issues include:

  • Stage probability values being rejected by HubSpot’s validation
  • Stage order not preserving the source pipeline’s sequence
  • Custom pipeline properties not available on the destination portal’s tier

Solution:

  1. Review the deployed pipeline stages in the destination portal
  2. Manually reorder stages if the order was not preserved
  3. Check that probability values are between 0 and 1 (HubSpot rejects values outside this range)
  4. Verify the destination portal’s tier supports all pipeline features

If none of the above solutions resolve your issue:

  1. Open the Activity Log and click on the failed deployment task
  2. Note the task ID and the specific error details
  3. Contact support at team@jetstack.ai with the task ID, the asset type, and a description of the failure