Skip to content

Properties

Properties define the data fields available on HubSpot objects (contacts, companies, deals, tickets, and custom objects). JetStack AI imports property definitions — not property values on individual records — and deploys them to target portals with intelligent conflict resolution.

HubSpot properties span a wide range of field types:

TypeField TypesNotes
stringtext, textarea, phonenumber, htmlStandard text entry
numbernumberNumeric values
datedateDate picker
datetimedatetimeDate and time picker
enumerationselect, radio, checkbox, booleancheckboxSingle or multi-select from options
currencynumber (special)Monetary values with currency display
scorecalculationLead scoring — NOT portable
calculationcalculationCalculated/rollup properties — NOT portable

Three property types cannot be automatically migrated via the HubSpot API:

  • Score — Lead scoring properties depend on portal-specific scoring rules
  • Calculation — Calculated properties use formulas that reference other properties by internal name
  • Rollup — Rollup properties aggregate data across associated records

These types are imported and displayed in the deploy wizard, but they are flagged as mapping requirements. During the mapping step, you must either manually create them in the target portal and map them, or exclude them from deployment.

Every property belongs to a property group. During deployment, JetStack AI checks whether the property’s group exists in the target portal. If the group is missing, it is auto-created before the property is deployed. The group is created with the same name and label as the source group.

Before creating a property, JetStack AI checks whether a property with the same internal name already exists on the same object type in the target portal. This check is cached per object type to minimize API calls — the first property deployment for an object type fetches the full property list, and subsequent properties for that object type use the cached result.

If a property with the same name already exists but has a different type or field type, JetStack AI cannot overwrite it (HubSpot does not allow changing a property’s type after creation). Instead, it creates a new property with a modified name using the suffix pattern:

  • {propertyName}_{type}_supr — If the base type differs
  • {propertyName}_{fieldType}_supr — If the field type differs

For example, if a property named lead_source exists as type string in the target portal but the source has it as type enumeration, JetStack AI creates lead_source_enumeration_supr in the target portal. A warning is logged so you can reconcile the properties manually after deployment.

For properties with options (select, radio, checkbox), JetStack AI performs a union merge of the source and target options:

  1. Fetch existing options on the target property (if it exists)
  2. Compare source options against target options by internal value
  3. Add any source options that do not already exist in the target
  4. Preserve all existing target options unchanged

This means deploying a property never removes options from the target — it only adds missing ones.

HubSpot defines 131+ system properties that are built into every portal (e.g., firstname, lastname, email, createdate, hs_object_id). These properties cannot be created or modified via the API. JetStack AI maintains a list of known system properties and automatically skips them during deployment. No error or warning is raised for skipped system properties.

The HubSpot API has an inconsistency with currency properties. In the source portal, currency properties are stored with fieldType: "currency", but the property creation API does not accept "currency" as a valid field type. JetStack AI transforms currency properties during deployment:

Source ValueDeployed Value
fieldType: "currency"fieldType: "number"
(added)displayMode: "current_value"
(added)showCurrencySymbol: true

This transformation requires using the v2 property API endpoint rather than the v3 endpoint. The result is visually and functionally identical to a currency property in HubSpot.

Some property names from source portals are invalid for creation via the API. JetStack AI detects and skips properties with names that match these patterns:

  • Numeric-only names — Names like 12345 or 001 (typically artifacts from system processes)
  • UUID-format names — Names matching UUID patterns (e.g., a1b2c3d4-e5f6-7890-abcd-ef1234567890)
  • Colon-containing names — Names with colons (e.g., hs:some_internal_prop) which indicate HubSpot internal properties

Skipped properties are logged with a warning explaining why they were excluded.

Properties are scoped to specific object types. A property named status on contacts is entirely separate from a property named status on deals. JetStack AI tracks and deploys properties per object type, and the existence cache is maintained separately for each object type.

  • “Property already exists with different type” — A property with the same name exists in the target portal but with an incompatible type. Check the deploy log for the _supr suffixed property that was created instead. You may want to manually migrate data between the old and new property.
  • Property group not appearing — The auto-created group should appear immediately. If it does not, check whether a group with the same internal name but different label already exists in the target portal.
  • Currency property looks like a number field — Verify that the property was created with showCurrencySymbol: true. If it was deployed via the v3 API by mistake, the currency display formatting may be missing.
  • Score/calculation property not deployed — These NOT_PORTABLE types must be manually created in the target portal. Use the mapping step to link the source property to a manually created target property.
  • Missing options on select property — Enumeration merging only adds options; it does not reorder them. If the option order matters, adjust it manually in HubSpot after deployment.