FluxCascade
FeaturesConnectorsPricingDocsBlog

Getting Started

  • Introduction
  • Quick Start
  • Core Concepts

Integrations

  • Overview
  • HubSpot
  • Jobber
  • Pipedrive
  • Salesforce

Field Mappings

  • Creating Mappings
  • Field Transformations
  • Bidirectional Sync
  • Conflict Resolution

Syncing Data

  • How Syncs Work
  • Scheduling
  • Webhooks
  • Error Handling

API Reference

  • Overview
  • Authentication
  • Connections
  • Mappings
  • Syncs
  • Webhooks

Guides

  • All Guides
  • HubSpot + Jobber
  • Deals to Jobs
  • Address Mapping

Security

  • Data Privacy
  • Encryption
  • Compliance

Support

  • FAQ
  • Troubleshooting
  • Contact Us

Address Mapping Guide

Addresses are one of the trickiest data types to sync between systems. Different platforms store addresses in different formats, and getting it right is crucial for field service operations.

The Challenge

Different Address Formats

HubSpot stores addresses as separate fields:

address: "123 Main Street"
city: "Springfield"
state: "IL"
zip: "62701"
country: "USA"

Jobber uses structured objects:

billing_address: {
  street1: "123 Main Street",
  street2: "",
  city: "Springfield",
  province: "IL",
  postal_code: "62701",
  country: "US"
}

Some systems use a single line:

full_address: "123 Main Street, Springfield, IL 62701"

Mapping Strategies

Strategy 1: Field-by-Field Mapping

Map each address component individually. Most reliable approach.

HubSpot FieldJobber Field
addressbilling_address.street1
address2billing_address.street2
citybilling_address.city
statebilling_address.province
zipbilling_address.postal_code
countrybilling_address.country

Pros:

  • Clean, reliable mapping
  • Each field syncs independently
  • Easy to troubleshoot

Cons:

  • More field pairs to configure
  • Doesn't work for single-line addresses

Strategy 2: Address Concatenation

Combine separate fields into a single line:

Source Fields: address, city, state, zip
Transform: address_single_line
Output: "123 Main Street, Springfield, IL 62701"

Pros:

  • Works when target only accepts single line
  • Compact display

Cons:

  • Harder to edit individual components
  • May lose structure

Strategy 3: Address Parsing

Split a single-line address into components:

Source: "123 Main Street, Springfield, IL 62701"
Transform: address_parse_street → "123 Main Street"
Transform: address_parse_city → "Springfield"
Transform: address_parse_state → "IL"
Transform: address_parse_zip → "62701"

Pros:

  • Works with single-line source data
  • Populates structured fields

Cons:

  • Parsing can fail on unusual formats
  • International addresses are tricky

Common Scenarios

HubSpot to Jobber

Billing Address:

  1. address → billing_address.street1
  2. city → billing_address.city
  3. state → billing_address.province
  4. zip → billing_address.postal_code

Service Address (Property):

Jobber separates clients from properties (service locations). You may need:

  1. Create a client with billing address
  2. Create a property with service address
  3. Link the property to the client

Pipedrive to Jobber

Pipedrive Persons have a single address field. Use parsing:

  1. address (parsed) → Each Jobber address component
  2. Or map to a notes field if parsing is unreliable

Multiple Address Types

Some contacts have both billing and service addresses:

HubSpot:

  • address, city, state, zip (mailing)
  • shipping_address, shipping_city, etc. (shipping)

Jobber:

  • billing_address (on Client)
  • Property address (separate object)

Map each type appropriately.

Address Transformations

State/Province Normalization

Different formats need normalization:

Input: "Illinois" or "illinois" or "IL"
Transform: state_abbreviation
Output: "IL"

Country Code Standardization

Input: "USA" or "United States" or "US"
Transform: country_iso2
Output: "US"

Postal Code Formatting

# US ZIP codes
Input: "627011234"
Transform: zip_format
Output: "62701-1234"

# Canadian postal codes
Input: "M5V1J1"
Transform: postal_code_format(country=CA)
Output: "M5V 1J1"

Handling Special Cases

Apartment/Unit Numbers

Some addresses have unit numbers mixed with street:

Input: "123 Main Street Apt 4B"

Option 1: Keep as-is in street1 Option 2: Parse into street1 + street2

Transform: address_parse_unit
street1: "123 Main Street"
street2: "Apt 4B"

International Addresses

International addresses vary widely:

UK:

123 High Street
London
SW1A 1AA
United Kingdom

Germany:

Hauptstraße 123
10115 Berlin
Germany

Recommendations:

  • Use field-by-field mapping when possible
  • Set default country if mostly domestic
  • Use address parsing carefully with international data

P.O. Boxes

Input: "P.O. Box 123"

Field service apps may reject P.O. boxes for service addresses. Consider:

  • Only sync to billing address
  • Flag records with P.O. boxes for review
  • Skip P.O. box addresses

Bidirectional Considerations

When syncing addresses both ways:

Who Owns the Address?

Decide which system is authoritative:

CRM-owned (recommended for billing):

  • Sales team updates billing addresses
  • Field team views only
  • Direction: CRM → Field Service

Field Service-owned (recommended for service locations):

  • Field teams update service addresses
  • They're on-site and know the correct location
  • Direction: Field Service → CRM

Conflict Handling

For bidirectional address sync:

  1. Set clear ownership by address type
  2. Use Last Write Wins for shared addresses
  3. Or flag conflicts for manual review

Validation

Before Sync

FluxCascade can validate addresses:

  • Required field checks (street, city must exist)
  • Format validation (postal code patterns)
  • Skip invalid addresses

Address Verification (Advanced)

For enterprise needs, consider:

  • USPS address verification integration
  • Geocoding for location accuracy
  • Standardization services

Contact support for advanced address validation options.

Troubleshooting

Empty Address Fields

Cause: Source address is incomplete

Solutions:

  • Make address fields non-required
  • Set default values
  • Skip records without addresses

Wrong State/Province

Cause: Format mismatch (full name vs abbreviation)

Solution: Add state normalization transform

Addresses in Wrong Fields

Cause: Field mapping incorrect

Solution: Review field pairs, ensure correct source → target

Special Characters Causing Issues

Cause: Certain characters not accepted by target

Solution:

  • Add character cleaning transform
  • Remove/replace problematic characters

Best Practices

  1. Map components separately when possible – More reliable than parsing

  2. Normalize early – Apply transforms to clean data before syncing

  3. Set appropriate field ownership – Don't sync addresses both ways without clear rules

  4. Handle missing data gracefully – Not all records have complete addresses

  5. Test with varied addresses – Include apartments, P.O. boxes, international

  6. Consider service vs. billing – They may need different handling

Next Steps

  • Field Transformations – All available transforms
  • HubSpot + Jobber Guide – Full integration setup
  • Bidirectional Sync – Two-way sync strategies
FluxCascade

The modern data integration platform. Connect your systems, sync your data, automate your workflows.

Product

  • Features
  • Pricing
  • Connectors
  • Changelog

Resources

  • Documentation
  • API Reference
  • Guides
  • Blog

Company

  • About
  • Contact
  • Privacy Policy
  • Terms of Service

Connect

  • Twitter
  • GitHub
  • Discord
  • LinkedIn

© 2026 FluxCascade. All rights reserved.

PrivacyTermsSecurity