Forms
Forms in HubSpot collect visitor data and can trigger workflows, redirect to pages, and send notification emails. JetStack AI captures the complete form definition — including field groups, dependent field logic, and post-submit actions — and reconstructs it in the destination portal with all references remapped.
What JetStack AI Captures
Section titled “What JetStack AI Captures”During import, JetStack AI retrieves the full form definition using both the v3 and v2 HubSpot APIs:
- Form metadata — name, form type, language, submit button text, style configuration
- Field groups — the structured layout of form fields organized into groups (max 3 fields per group for side-by-side display)
- Fields — each field’s property name, label, field type, required status, placeholder text, validation rules, and option values
- Dependent fields — conditional fields that appear based on another field’s value, including the condition logic
- Post-submit actions — what happens after form submission: redirect to URL, display inline message, or redirect to a page
- Notification configuration — recipient owner IDs, team IDs, and email addresses for submission notifications
V2 vs V3 API Handling
Section titled “V2 vs V3 API Handling”HubSpot has two form API versions with different data models. JetStack AI uses v3 as the primary API for both import and deploy, but enriches the data with v2 for fields that are invisible in v3:
followUpId— the ID of a workflow triggered on form submission. This field only appears in the v2 API response.dependentFieldFilters— the detailed condition configuration for dependent fields. The v3 API acknowledges dependent fields exist but omits the filter logic.
During deploy, JetStack AI creates the form via the v3 API, then applies v2-only fields via a separate v2 API PATCH call. This two-step approach ensures all form data is faithfully reproduced.
Dependencies
Section titled “Dependencies”Forms reference several other asset types:
| Dependency Type | Where It Appears |
|---|---|
| Workflows | followUpId (submission trigger), post-submit workflow enrollment |
| Pages | Post-submit redirect URL, page-specific form embedding |
| Properties | Every form field maps to a HubSpot property |
| Owners | Notification recipient configuration |
| Teams | Notification recipients in team:XXXX format |
| Lifecycle stages | Lifecycle stage field options and set-on-submit actions |
| Subscription types | Consent/subscription checkboxes on GDPR-enabled forms |
Deploy Remapping
Section titled “Deploy Remapping”When deploying a form to the destination portal, JetStack AI transforms:
Field Group Transformation
Section titled “Field Group Transformation”- Field groups are preserved with their layout structure (up to 3 fields side-by-side per group)
- Property internal names are remapped to the destination portal’s property names
- Field option values (dropdowns, radio buttons, checkboxes) are remapped to match the destination property’s options
- Field validation rules are preserved as-is
Dependent Field Conditions
Section titled “Dependent Field Conditions”Dependent fields show or hide based on a parent field’s value. JetStack AI remaps:
- The parent field’s property name to its destination equivalent
- The condition values that trigger the dependent field — these are remapped through the property option mapping to ensure they match the destination property’s option values
- The dependent field’s own property name
Notification Recipients
Section titled “Notification Recipients”Form submission notifications can target owners, teams, and static email addresses:
- Owner IDs are remapped to the corresponding destination portal owners
- Team IDs (stored in
team:XXXXformat) are remapped to the destination team IDs - Static email addresses are preserved as-is
Post-Submit Actions
Section titled “Post-Submit Actions”- Redirect to URL — if the URL points to a page in the source portal, it is remapped to the equivalent page URL in the destination
- Redirect to page — the page ID is remapped to the destination page’s ID
- Inline thank you message — preserved as-is (HTML content)
Edge Cases and Special Handling
Section titled “Edge Cases and Special Handling”Max 3 Fields Per Group
Section titled “Max 3 Fields Per Group”HubSpot enforces a maximum of 3 fields per field group. If the source form has groups exceeding this limit (possible in older forms created before the restriction), JetStack AI automatically splits oversized groups into multiple groups of 3 or fewer fields during deploy.
V2-Only Fields Applied Separately
Section titled “V2-Only Fields Applied Separately”After the v3 form creation call succeeds, JetStack AI makes a separate v2 API call to apply followUpId and dependentFieldFilters. If the v2 call fails (e.g., the follow-up workflow was not deployed), the form is still created successfully — it simply lacks the v2-only configuration. Check the deploy log for v2 enrichment warnings.
File Upload Fields
Section titled “File Upload Fields”File upload fields include an objectTypeId that specifies which object type the file is associated with. JetStack AI remaps this object type ID for custom objects but preserves standard object type IDs (contacts, companies, deals, tickets).
Consent Fields and GDPR
Section titled “Consent Fields and GDPR”Forms with GDPR consent checkboxes include subscription type references. These are remapped to the destination portal’s subscription types. If a subscription type does not exist in the destination, the consent field will reference an invalid ID — ensure subscription types are included in the import.
Troubleshooting
Section titled “Troubleshooting”Dependent Field References to Unmapped Fields
Section titled “Dependent Field References to Unmapped Fields”If a dependent field’s parent property was not included in the import, the dependency condition cannot be remapped. The dependent field will be deployed without its conditional logic, appearing as a standard (always-visible) field. To fix this, re-import with the missing property included and redeploy.
Option Value Mismatches
Section titled “Option Value Mismatches”When the source and destination properties have different option values (e.g., different internal names for the same dropdown choices), dependent field conditions may not trigger correctly. Review the property mapping to ensure option values align. JetStack AI maps options by label when internal names differ, but custom option values that were renamed may not match.
Form Fields Referencing Non-Existent Properties
Section titled “Form Fields Referencing Non-Existent Properties”If a form field references a custom property that does not exist in the destination portal, the field will be omitted from the deployed form. Ensure all required custom properties are deployed before deploying forms that use them.