Skip to content

Lists

Lists are a foundational asset type in HubSpot. Nearly every other asset — workflows, emails, forms, reports — can reference lists. JetStack AI captures the full list definition, including all filter logic, and reconstructs it in the destination portal with every internal ID remapped.

During import, JetStack AI retrieves:

  • List metadata — name, object type (contacts, companies, deals), processing type, and creation details
  • Filter definition — the complete recursive filter tree with all branches, conditions, and nested references
  • Processing type — whether the list is dynamic (auto-updating) or static (point-in-time snapshot)

HubSpot distinguishes between static and dynamic lists. JetStack AI handles the conversion:

  • Dynamic lists are imported and deployed with their full filter definition intact. The destination list will evaluate its filters against the destination portal’s data.
  • Static lists use SNAPSHOT processing in the source portal. JetStack AI converts these to MANUAL processing type during deploy, since the original snapshot records do not exist in the destination portal. The list structure is preserved, but the membership is not transferred.

HubSpot lists support 20+ filter types organized in a recursive OR/AND logic structure. Each filter branch can contain:

  • OR groups — top-level branches where any matching group qualifies a record
  • AND conditions — within each OR group, all conditions must be met

JetStack AI handles all filter types, including:

Filter TypeDescription
Property filtersCompare a property value (equals, contains, greater than, etc.)
List membershipRecord is/is not a member of another list
Form submissionRecord submitted a specific form (optionally on a specific page)
Email interactionRecord opened/clicked/received a specific email
Workflow membershipRecord is/was enrolled in a workflow
Page viewRecord viewed a specific page URL
CTA interactionRecord clicked a call-to-action
Owner assignmentRecord is assigned to a specific owner
Subscription statusRecord’s email subscription preferences
Pipeline stageRecord is in a specific pipeline/stage
Lifecycle stageRecord’s current lifecycle stage
Event-basedBehavioral events and custom event completions

Lists can reference a wide range of other assets within their filter conditions:

  • Other lists — nested list membership checks (list A filters on membership in list B)
  • Forms — form submission filters
  • Emails — email engagement filters
  • Workflows — workflow enrollment filters
  • Pages — page view and form-on-page filters
  • Owners — owner assignment filters
  • Subscription types — email subscription filters
  • Lifecycle stages — lifecycle stage property filters
  • Pipelines — deal/ticket pipeline and stage filters

JetStack AI resolves all of these during import and ensures they are deployed in the correct dependency order.

When deploying a list to the destination portal, JetStack AI performs a full transformation of the filter tree:

  • Property names — custom property internal names are remapped if they differ between portals
  • List IDs — nested list references are replaced with the destination list’s ID
  • Owner IDs — owner filters are remapped to the corresponding destination owner
  • Pipeline stage IDs — stage filters are remapped based on the pipeline mapping configuration
  • Enum option values — property options (dropdowns, radio selects) are remapped to their destination equivalents
  • Subscription type IDs — subscription filters are remapped to the destination portal’s subscription types
  • Email campaign group IDs — email engagement filters reference campaign group IDs, which are resolved from the deployed email’s campaign data
  • Form IDs — form submission filters are remapped to the destination form

JetStack AI also performs duplicate detection by name before creating a list. If a list with the same name already exists in the destination portal, JetStack AI will use the existing list’s ID rather than creating a duplicate.

Time-based filters (e.g., “property was updated in the last 30 days”) use a specific structure that has several pitfalls:

  • Field name mismatch — HubSpot’s GET API returns upperBoundEndpointBehavior to indicate whether the upper bound is inclusive or exclusive. The field name is upperBoundEndpointBehavior, not upperBoundEndpoint. JetStack AI correctly maps this field during deploy.
  • IANA timezone rejection — HubSpot’s POST/PUT API rejects IANA timezone identifiers like America/New_York. JetStack AI automatically converts these to the legacy format HubSpot accepts (e.g., US/Eastern).
  • indexReference.referenceType validation — HubSpot only accepts TODAY or NOW as valid referenceType values when creating lists. Values like MONTH that appear in GET responses are rejected on create. JetStack AI strips or transforms these invalid reference types.

If list A filters on membership in list B, and list B filters on membership in list A, a circular dependency exists. JetStack AI detects circular references during dependency resolution and will deploy the lists in a two-pass approach — creating one list without the circular filter, then updating it after the other list exists.

Email engagement filters (opened, clicked, received) reference a campaignGroupId rather than the email’s content ID. This campaign group ID is not immediately available after deploying an email. JetStack AI resolves the campaign group ID by querying the email’s campaign data after deploy and patches the list filter accordingly.

List filters that reference recently deployed assets may encounter stale cache issues in the HubSpot API. If a list deploy fails due to an unrecognized asset ID, JetStack AI will retry the operation after a brief delay.

If a list contains TIME_RANGED filters with IANA timezones, JetStack AI automatically retries with the converted timezone format. If the conversion fails (unrecognized timezone), the deploy error will include the original timezone string. Verify that the source list’s timezone is a standard IANA identifier.

JetStack AI checks for existing lists with the same name before creating a new one. If a list already exists in the destination, it will be reused. This can cause unexpected behavior if two different source lists share the same name — the second will be mapped to the first destination list. Use distinct list names to avoid conflicts.

If a list filter references an asset (form, email, workflow) that was not included in the import, the filter condition will fail to remap. JetStack AI logs a warning and deploys the list without the unresolvable filter condition. Check the deploy log for “unresolved reference” warnings.