Salesforce + Hubspot

This guide walks you through recommendations for CRM sync, connecting Starbridge to Salesforce or HubSpot, choosing an account-matching strategy, and setting up Lookup and Sync columns inside a bridge.

Video Walkthrough

Account Matching

Account matching is the critical first step in any CRM integration process. It ensures Starbridge can place relevant data and signals into the correct Account/Company in your CRM so insights, contacts, and account data are properly associated.

Starbridge supports two primary ways to perform account matching:

External identifiers (NCES / IPEDS / GEOID)

If you sell into a market with widely used unique identifiers, most teams find it easiest to match using these identifiers directly.

Common examples:

• School districts: NCES IDs
• Higher education: IPEDS IDs
• Cities and counties: Census GEOIDs

1. Confirm identifier coverage in your CRM

   Make sure your CRM already contains these identifiers across your Account/Company records.

   NCES IDs contain leading zeros and must be stored in your CRM as text, not numbers.

2. Use the identifier for your CRM lookup

   In Starbridge, create a Lookup Record in CRM column and add a lookup rule that matches the Starbridge identifier field to the corresponding CRM field (for example, Starbridge NCES ID → CRM NCES ID).

3. (Optional) Add sequential matching for multiple identifiers

   If you sell across buyer types (for example, school districts and higher education), use if-then-else logic to match in order.

   Example: match on NCES ID → if no match, then match on IPEDS ID.

   A given Starbridge buyer will only carry one of these identifiers, so each row will only run one match attempt.

Domain matching is not recommended. Domains change frequently, may duplicate across buyers, and often have low data quality in CRMs.

Starbridge ID

If you sell into many different buyer types (including those without standardized identifiers, such as state agencies or special districts), we recommend using the Starbridge ID as your universal key.

1. Add a Starbridge ID field in your CRM

   Create a custom field on your Account/Company object called

   Starbridge ID

   . This becomes the permanent link between Starbridge and your CRM.

2. Populate Starbridge IDs

   Customer-defined matching

   Starbridge can provide an export of all Starbridge accounts in your TAM (including account attributes like name, state, identifiers, and domains). You can then:

   1. Match those Starbridge accounts to your CRM accounts manually or programmatically.

   2. Write the corresponding Starbridge ID into the CRM

      Starbridge ID

      field.

   Teams prefer this approach when they want full control and the ability to augment their CRM with any missing accounts.

   Starbridge AI matching

   Alternatively, you can use Starbridge’s AI matching technology:

   1. Provide your Starbridge Customer Solutions Architect with a CRM export of your accounts (at minimum: name and state). The more fields you provide (domains, identifiers, zip codes, etc.), the higher quality the match.
   2. Starbridge runs the match and returns a list of your accounts with matched Starbridge IDs.
   3. Write the matched Starbridge IDs into your CRM field.
3. Configure your CRM lookup rule

   When creating your CRM syncs in Starbridge, create a Lookup Record in CRM column that finds the corresponding Account/Company record:

   • Add a lookup rule for your CRM

     Starbridge ID

     field.

   • Match the

     Starbridge ID

     in each Starbridge buyer row to the

     Starbridge ID

     field in your CRM.

   This creates a consistent one-to-one mapping across buyer types.

Connect your CRM to Starbridge

1. Navigate to the Salesforce or HubSpot integration

   Go to Settings → Integrations, then select Salesforce or HubSpot.

   If you want to connect a sandbox first (and keep separate sandbox and production connections), connect Salesforce/HubSpot from the instance you want to use.

2. Authenticate to Salesforce or HubSpot

   Log into your Salesforce or HubSpot account.

   The user you connect must have permission to read and write the objects you want Starbridge to access. To avoid complexity, many teams use an admin user and/or a dedicated integration user for clarity in audit trails.

   Salesforce app restrictions: Salesforce has introduced stricter controls on uninstalled connected apps. To authorize Starbridge the first time, the authenticating user must have Salesforce’s Approve Uninstalled Connected Apps (or Use Any API Client) system permission. After a successful OAuth, the app appears under Connected Apps OAuth Usage where you can manage policies and assign it to additional users.

3. Configure objects and fields Starbridge can access

   After connecting, your Salesforce or HubSpot account appears in a Pending setup state.

   Click the three-dots menu → Edit configuration objects. In the configuration panel, you can:

   • Rename the Salesforce or HubSpot connection.
   • Choose which objects Starbridge can access.
   • For each selected object, choose which fields Starbridge can access.
     • Required fields are included automatically.
     • You can optionally grant access to additional fields.

   Starbridge will only access, edit, or create data within the objects and fields you explicitly select. It’s usually best to include all fields you might want to integrate later—this only grants access and does not pull or push data by itself.

4. Save and run the initial sync

   Click Save to trigger the initial sync between your CRM and Starbridge.

   You’ll see a Syncing status while the initial sync runs (duration depends on the size of your CRM instance). When complete, the status becomes Synced.

Lookup columns: access CRM objects in a bridge

Once your CRM account is connected, you can pull CRM data into Starbridge by creating Lookup Record in CRM columns.

1. Add a CRM lookup column

   Open the bridge where you want to access CRM data, then click Add column → Configure integration → Lookup Record in CRM.

2. Configure the lookup

   • Name the column (for example, “CRM Account Lookup”).
   • Choose the CRM account you want to use.
   • Select the object type to look up (for example, Account, Contact, Opportunity).
3. Define matching logic

   Create a set of matching rules to determine which CRM object should be returned for each row. Lookup rules work as a series of if-else statements; each block can include any number of comparisons between CRM fields and bridge data.

   One object per row: a lookup can only return a single object per row. If multiple objects match, you’ll see a multiple match indication.

4. Review lookup results

   Once configured, the column populates with results:

   • No match: no CRM object matched your rules
   • One match: a single object was found
   • Multiple matches: more than one object matched your rules

   You can click into a cell to view details of the matched object.

5. Use the lookup column

   Lookup columns behave like any other multi-return value column:

   • Use the lookup output as an input to other columns (for example, AI Analysis or Web Agent columns).
   • Pull specific values from the lookup as reference columns:
     1. Go to Reference existing data.
     2. Select Reference a column.

   You can add multiple CRM lookup columns within the same bridge.

Sync columns: write data from Starbridge to your CRM

Starbridge can also push data into Salesforce or HubSpot by creating Sync Record in CRM columns.

1. Prepare your bridge

   Before syncing, ensure your bridge contains the data you want to push into CRM. In many cases you’ll first use one or more lookup columns to find existing CRM records that should be updated.

   Example: if syncing contacts, you might use one lookup to find the related account and another lookup to check whether the contact already exists in CRM.

2. Add a sync column

   Click Add column → Configure integration → Sync Record in CRM. Name the column, select the CRM account, and choose the object type to sync (for example, Account, Contact, Opportunity, or a custom object).

3. Choose a sync option

   Create and manage record

   • Creates a new record and (optionally) keeps it updated if attributes in Starbridge change.
   • Options:
     • Only create if no matching record exists (requires a lookup column).
     • Keep created records up to date (toggle whether updates are pushed when data changes in Starbridge).

   Upsert (update or insert)

   • Requires a lookup column.
   • If a match exists → updates the record.
   • If no match exists → creates a new record.

   Update only

   • Requires a lookup column.
   • If a match exists → updates the record.
   • If no match exists → no action is taken.
4. Map fields

   Starbridge displays CRM fields on the left. For each one, select a field from your bridge to sync on the right (only type-compatible fields can be mapped).

   Field update options:

   • Write if empty: only fills the field if it has no current value.
   • Overwrite field: always overwrites any existing value.
5. Review sync results

   After the sync column is added, each cell displays a sync status:

   • Success
   • No action taken
   • Error (with an error message)

   Click into a cell to see a history of syncs for that row.

Use case walkthroughs

This section describes how Starbridge CRM Sync works in common real-world scenarios. The steps and ordering below should be treated as requirements for product behavior and documentation.

Account-level sync: write Starbridge account data to CRM Account/Company

This flow is used when you want to write account-level data from Starbridge into CRM Account/Company objects (for example, enrollment/population data, Account Score, Account Scoring Rationale, and other account enrichment).

1. Identify which CRM account fields Starbridge should write to

   Determine which fields on your CRM Account/Company object should receive data from Starbridge.

   Examples:

   • Standard CRM account fields
   • Custom fields created specifically for Starbridge data
   • Custom number/text/formula fields used for scoring or enrichment

   Starbridge will not sync to any field unless you explicitly select and map it.

2. Expose those fields to Starbridge in the integration configuration

   In your Starbridge CRM integration configuration, add the fields you want Starbridge to read/write so they appear as selectable fields in sync mappings.

3. Add a lookup column to find the existing CRM account

   In your bridge, add a Lookup Record in CRM column for the Account/Company object and configure it using your account lookup criteria (see account matching).

   The goal is to find the correct CRM Account/Company object for each row so Starbridge updates the right record.

4. Add a sync column for the account object

   Add a Sync Record in CRM column, select the Account/Company object, and set the sync type to Update.

5. Map Starbridge bridge columns to CRM account fields

   Map each Starbridge column to the corresponding CRM Account/Company field and confirm data types are compatible (text → text, number → number, etc.).

6. Choose the write behavior for each field

   For each mapped field, choose:

   • Overwrite (always write, replacing CRM)
   • Write if empty (do nothing if CRM already has a value)
7. Run the sync

   Once the lookup column consistently resolves the correct CRM record and the sync column is configured and mapped, run the sync to update CRM Account/Company records.

Contacts sync: create/update CRM Contacts

Video: Syncing contacts from Starbridge to Salesforce

This scenario covers syncing contact-level data from Starbridge into your CRM Contact object, including creating new contacts, updating existing contacts, and ensuring contacts are associated to the correct account.

Best practice: add two custom fields to the CRM Contact object

We strongly recommend adding two custom fields before configuring a contact sync:

• Starbridge ID (text): the unique identifier of every Starbridge contact
  • Enables lookups by Starbridge contact identifier
  • Helps admins identify which contacts were created or modified by Starbridge
• Starbridge Active (boolean): whether Starbridge considers the contact currently active
  • Defaults to true for active contacts
  • Set to false when Starbridge detects the contact is no longer in role or the email address is no longer valid

1. Ensure Starbridge has access to the Contact and Account objects

   In the integration configuration, confirm:

   • Starbridge can access the Contact object.
   • Starbridge can read/write required fields (including the custom fields above, if you add them).
   • Starbridge can access the Account/Company object (contacts must be associated to an account).

   Granting access in the integration configuration does not pull or push data. It only enables Starbridge to use those objects/fields later in lookup and sync mappings.

2. Create two lookup columns in your bridge

   Create two separate lookup columns:

   • Lookup 1: related account (Account/Company) — used to associate each contact to the correct account
   • Lookup 2: existing contact (Contact) — used to decide whether to update an existing record or create a new one

   In the Contact lookup, we recommend an IF/ELSE structure: IF email matches (using the normalized email), ELSE match by Starbridge Contact ID.

3. Add a sync column for the Contact object (Upsert)

   Add a Sync Record in CRM column for the Contact object and set the sync type to Upsert.

   • If a match exists (via email or Starbridge ID) → update the contact
   • If no match exists → create a new contact
4. Map Starbridge fields to CRM Contact fields

   Map each Starbridge column to the appropriate CRM Contact field and choose per-field write behavior (Overwrite vs Write if empty).

   When creating contacts, map the Account ID returned from the related account lookup to the contact’s Account/Company relation field so new contacts are properly associated.

   HubSpot: if the Company ID (Relation to Company) value isn’t available in the related account lookup, see Managing relations in HubSpot.

   Recommended best practice: set Starbridge Active to Overwrite so it can update when a contact becomes inactive.

5. Add recommended run conditions

   Many teams add run conditions to prevent unwanted or incorrect contact creation. We recommend:

   • Hard recommendation: only run if the related Account lookup’s Record ID is not empty (prevents orphan contacts)
   • Optional but recommended: only run if the Starbridge email address is not empty (avoids unusable contacts)

Job change sync: create/update job change records in CRM

This scenario covers syncing job change data from Starbridge into your CRM.

By syncing job changes to your CRM, you can:

• Capture warm signals such as new hires to target roles in your ICP accounts
• Flag retention risks when key contacts - like executive sponsors or champions - depart from customer accounts or new warm contacts when former champions move to new accounts
• Maintain a historical record of all relevant job changes across your target accounts

2-Minute Explanation: What You're Actually Doing

When Starbridge identifies a job change, you get two things:

1. A contact — the person who changed jobs
2. A signal — the event itself (“Person X became VP at Company Y on Feb 1st”)

We recommend you sync both.

The Basic Flow

1. Sync the contact to Contact object — Create a new contact or update an existing contact with current info (name, title, email, company)
2. Action the signal — Via Starbridge Feed or as a Job Change object in CRM

Foundation: Always sync contacts to Contact object

Regardless of which path you choose below, always sync contacts to your Contact object. This keeps your contact data clean and up-to-date.

Why separate the contact from the signal?

• Contacts = current state (“Sarah is currently VP of Sales at Acme Corp”)
• Signals = historical events (“Sarah was promoted to VP on Jan 15th” — this never changes)

Keeping contacts updated in your CRM while consuming signals separately (whether in Starbridge or as CRM records) gives you both current data and historical context.

Then: Choose how to consume job change signals:

• Path 1: Starbridge Feed (simplest, no additional CRM setup) — Review signals in Starbridge and via email digest
• Path 2: Job Change custom object (most flexible, best reporting) — Historical tracking and complex workflows with a Salesforce/HubSpot admin. Your reps can still review signals in Starbridge and via email digest

Common Use Cases

Before diving into setup, understand the primary ways teams use job change data:

Use Case 1: New Hires & Promotions at ICP Accounts

• What it is: Track when target titles join or get promoted at your ICP accounts
• Why it matters: Warm outbound opportunities, purchase decisionmaker changes
• Typical workflow: SDR/BDR creates lead or task for outreach

Use Case 2: Champion Tracking

2a. Tracking Departing Champions

• What it is: Alert when champions leave customer accounts
• Why it matters: Retention risk, need to identify new champion
• Typical workflow: CSM/AM creates task to find replacement champion

2b. Tracking Champions Moving to New Companies

• What it is: Track when current champions OR people from champion accounts move to new ICP companies
• Why it matters: Warm intro at new account, pre-existing relationship
• Typical workflow: AE creates task to reconnect, or SDR creates lead

Path 1: Starbridge Feed

Best for: Teams getting started who want to see value immediately without complex CRM setup.

Supports: All use cases above

How It Works

1. Contacts are synced to Contact object with current information (this keeps your CRM contact data fresh)
2. Job change signals stay in Starbridge — you review them in the Starbridge Feed
3. Email digest sends you daily or weekly summaries of high-priority job changes
4. Manual action — when your reps see a relevant signal, they can reach out directly or create a lead

1. Sync Contacts to Contact Object

   Follow the instructions in this Contacts sync use case walkthrough.

   This ensures every person is in your CRM as a Contact with current information.

2. Create a Review Workflow

   Establish a routine for your reps to act on signals:

   • Reps can log into Starbridge and review their feed, or look at their email digest
   • Reps can manually create leads or tasks in your CRM
   • Reps can track signals they’ve actioned (use Starbridge’s built-in status flag)

How to Configure Bridges for Each Use Case

For Use Case 1: New Hires & Promotions at ICP Accounts

Bridge Configuration:

• Job Change Types: Track “New Joiners” and “Title Changes”
• Buyer List: ICP prospect accounts (companies you want to sell to)
• Titles to track: Target decision-maker titles relevant to your product (e.g., VP of Sales, CIO, Director of Operations)

Who Reviews: SDRs/BDRs monitor feed and create leads or tasks for outreach

For Use Case 2a: Tracking Departing Champions

Bridge Configuration:

• Job Change Types: Track “Departures” only
• Buyer List: Customer accounts (companies currently using your product)
• Titles to track: Champion roles or titles that typically sponsor your solution
• Additional Filter: Look up contacts in CRM and filter to those marked as Champion/Executive Sponsor

Who Reviews: CSMs/AMs monitor feed and create tasks to identify replacement champions

For Use Case 2b: Tracking Champions Moving to New Companies

Bridge Configuration:

• Set up a bridge the same as described above for Use Case 1.

Who Reviews:

• Reps review job changes and confirm in your CRM whether the contact was a champion at their previous employer.
• If previous champion: AE creates task to reconnect
• If not: SDRs create lead for net-new outreach

When to Graduate to Path 2

Consider moving to automated CRM sync for job change signals when:

• You have clear patterns of which signals always require action
• Your team wants automated task creation or routing
• You need job change data in CRM reports and dashboards

Path 2: Custom Object Setup

Best for: Teams with a Salesforce/HubSpot admin who want maximum flexibility, historical tracking, and robust reporting on job change trends.

Supports: All use cases above, with automated workflows and rich reporting

We strongly recommend modeling job changes as a dedicated custom object rather than as ad-hoc fields on contacts or accounts.

Why?

• History-preserving: Each job change is stored as a separate transaction, so you can track a contact across multiple title changes without losing context
• Flexible linking: You can link job changes to the contact and account, enabling robust reporting
• Clean UI: Contacts maintain simple state flags while complex relational logic lives on the job change object
• Reporting-friendly: Easy to answer questions like “How many champions left ICP accounts last quarter?” or “Which accounts have lost key contacts in the last 90 days?”

Core Custom Object Structure

Create a custom object called Job Change (or Signal: Job Change) with these core fields:

Lookup fields (relationships):

• Contact (Lookup → Contact) — The person experiencing this job change event
• Account (Lookup → Account) — The account associated with the Contact

Core metadata fields:

• Job Change Type (Picklist) — New Joiner, Title Change, or Departure
• Effective Date (Date) — When the job change takes effect
• Announced Date (Date) — When the job change was announced (might be before the job change takes effect)
• Summary (Long Text) — Description of the job change

Enriched descriptive fields:

• Current Title (Text) — The person’s current title
• Previous Title (Text) — Their previous title (for Title Changes)

Deduplication field:

• Job Change ID (External ID, Text) — Starbridge’s unique identifier for this job change event

ICP/prioritization flags (optional):

• Account ICP? (Checkbox)
• Contact Champion? (Checkbox)

This structure allows you to continuously add fields as your GTM motion evolves without cluttering your base Contact or Account schema.

Important: Job Change records are signals — immutable events that happened at a point in time. Separately, you should sync contacts from Starbridge to keep your Contact records up-to-date with current information. The Job Change object preserves the historical context of career transitions.

1. Create the Job Change Custom Object in Your CRM

   Before syncing anything from Starbridge:

   1. Create the Job Change custom object in your CRM with the fields described above
   2. Define relationships (lookups) to both Contact and Account objects:
      • Contact → Contact
      • Account → Account
   3. Mark Job Change ID as an External ID field (this enables upsert operations and prevents duplicate job change records)
2. Expose the Job Change Object to Starbridge

   Go to your Starbridge → CRM Integration Configuration and ensure:

   • Starbridge can read and write to the Job Change custom object
   • All fields you want to populate are exposed (including relationship/lookup fields)
   • Starbridge can also access the Contact and Account objects (required for lookups)
3. Enrich the Job Change ID

   Before looking up CRM records, enrich the Job Change ID from Starbridge:

   1. Add a column → Enrich Job Change Info
   2. Select Job Change ID

   This provides Starbridge’s unique identifier for each job change event, which you’ll use to prevent duplicate records in your CRM.

4. Sync the Contact to Your CRM

   Before creating Job Change records, sync the contacts themselves to your CRM. This ensures that when you create Job Change records with contact lookups, the contacts already exist in your CRM.

   Follow the instructions in this Contacts sync use case walkthrough.

   Why sync contacts separately from job change signals?

   • Job Changes = immutable historical events (“Person X left Company A on 2024-03-15”)
   • Contacts = current state that changes over time (“Person X currently works at Company B as VP of Sales”)
   • Keeping them separate ensures your Contact records stay up-to-date with current information while Job Change records preserve the historical context of career transitions
   • This prevents confusion about which record holds the “source of truth” for current contact information
5. Add a 'Sync Data to My CRM' Column for the Job Change Object

   Now you’re ready to create or update job change records in your CRM.

   1. Add a new column → Sync data to my CRM
   2. Select the Job Change custom object
   3. Set the sync type to: Create and Manage Record

   In the sync column configuration, map your Starbridge bridge columns to CRM fields.

6. Set Up CRM Automations to Action Job Changes

   Once job changes are syncing to your CRM, the real value comes from automating actions based on these signals.

   Recommended Automations for Salesforce and HubSpot Admins

   Once job changes are syncing to your CRM, set up automations to route signals to the right people based on the use cases described in Path 1.

   Automation 1: Create Tasks for New Hires and Promotions at ICP Accounts

   Supports: Use Case 1 (New Hires & Promotions at ICP Accounts)

   Trigger: New Job Change record created where:

   • Type = “New Joiner” or “Title Change”
   • Account is on your ICP buyer list (e.g., Account ICP checkbox = true, or specific industry/size criteria)
   • Current Title matches target decision-maker titles (e.g., CIO, Superintendent, VP of Sales)

   Action:

   • Create a Task assigned to the Account Owner or SDR/BDR owner
   • Task Subject:
     • New Hire: [Contact Name] → [Current Title] @ [Account]
     • Promotion: [Contact Name] → [Current Title] @ [Account]
   • Related To: Account and Contact
   • Due Date: 7 days from job change effective date
   • Priority: High
   • Description: Include link to Job Change record, summary of the job change

   Automation 2: Flag Retention Risks for Departing Champions

   Supports: Use Case 2a (Tracking Departing Champions)

   Trigger: New Job Change record created where:

   • Type = “Departure”
   • Account is a customer account (active customer, not prospect)
   • Contact is marked as Executive Sponsor, Champion, or Primary Contact on an active opportunity, renewal, or customer account

   Action:

   • Create a Task assigned to the CSM or AM owner of Account
   • Task Subject: Retention Risk: [Contact Name] departing from [Account]
   • Related To: Account, Contact, and active Opportunity
   • Due Date: Immediate (or before effective date if future-dated)
   • Priority: Urgent
   • Description: “Key contact departing. Schedule call to identify new champion and address any transition risks.”

   Automation 3: Route Champions Moving to New ICP Accounts

   Supports: Use Case 2b (Tracking Champions Moving to New Companies)

   Trigger: New Job Change record created where:

   • Type = “New Joiner”
   • Account is on your ICP buyer list
   • Contact is marked as Champion or Executive Sponsor in your CRM (from their previous company)

   Action:

   • Create a Task assigned to the AE or Account Owner
   • Task Subject: Champion Moved: [Contact Name] → [Current Title] @ [Account]
   • Related To: Account and Contact
   • Due Date: 3 days from job change effective date
   • Priority: High
   • Description: “Former champion now at new ICP account. Warm intro opportunity. Link to previous account: [Previous Account]. Link to Job Change record.”

   Automation 4: Slack or Teams Notifications for High-Priority Signals

   For high-priority job changes, send Slack or Teams notifications in addition to or instead of tasks:

   When to use:

   • Champions departing (Use Case 2a) — immediate visibility for urgent retention risk
   • Champions moving to new ICP accounts (Use Case 2b) — high-value warm intro opportunity
   • Executives joining key accounts (Use Case 1) — C-level hires at top-tier ICP accounts

   Setup:

   • Post to a dedicated #job-changes or #warm-signals channel
   • Include: Contact name, job change type, account, link to CRM record
   • Tag relevant team members or use Slack workflows to route to the right person based on account owner
7. Reporting and Dashboards

   With job changes as a dedicated object, you can build powerful reports:

   Example reports:

   • “Champions who moved to ICP accounts in the last quarter” (Type = “New Joiner” where Contact Champion = true, Account ICP = true)
   • “Accounts that lost key contacts (departures) in the last 90 days” (Type = “Departure”, Account = customer)
   • “New hires at target accounts by job title and month” (Type = “New Joiner”, grouped by Account and Current Title)
   • “Job changes by type over time (trend analysis)”

   Example dashboard widgets:

   • Count of job changes by type (New Joiner, Title Change, Departure)
   • List of open tasks created from job change automations
   • Accounts with the most job change activity (high turnover signal)

Alternative Approaches

Alternative #1: CRMs Without Custom Object Support

If your CRM or CRM plan does not support custom objects, you can use a simplified approach that adds custom fields directly to the Contact object.

This is not recommended if your CRM supports custom objects, but it provides a workable alternative.

Custom Fields to Add on Contact Object

Add the following custom fields to your Contact object:

• Started Date (Date) — When the contact started at this employer
• Ended Date (Date) — When the contact left this employer

Bridge Configuration

1. Set up lookup for Contact as described in Path 2 Step 4
2. Create the Sync to Contact column
3. Map contact fields conditionally based on job change type:
   • For New Hires (Type = “New Joiner”):
     • Map Effective Date to Started Date
     • Map standard contact fields (name, title, email, etc.)
   • For Departures (Type = “Departure”):
     • Map Effective Date → Ended Date
   • For Title Changes (Type = “Title Change”):
     • Map standard contact fields (new title, etc.)

Automations

Build automations that trigger on Contact field updates:

• New Hire tasks: Trigger when Started Date is updated AND contact is at an ICP account with target title
• Departure tasks: Trigger when Ended Date is updated AND contact is at customer account

Limitations

• No clean way to track promotions: Title Changes overwrite contact data without preserving history of the promotion event itself
• Conflates signals with state: Job change events (immutable historical signals) are mixed with contact state (mutable fields that change over time)
• Loss of history: When a contact has multiple job changes, you lose the historical record of previous title changes

If your CRM supports custom objects, always use the dedicated Job Change object approach (Path 2).

Alternative #2: Syncing Job Change Contacts as Leads

Note: This approach is not recommended. We strongly recommend syncing contacts to the Contact object as your foundation (as described in Paths 1 and 2 above).

Why we don’t recommend syncing Leads:

• Can’t maintain clean champion tracking: If a champion moves to a new company, you want to preserve their “champion” status and relationship history. With Leads, this context gets lost.
• Can’t keep contacts up-to-date over time: When you sync contacts from Starbridge to your CRM, Starbridge will keep them up to date over time as their email, phone, title, or employment status changes. If you sync contacts as Leads, Starbridge may not be able to keep the CRM contact up to date over time.

To Sync Contacts as Leads

If your team strongly prefers this approach despite the limitations:

1. In your Job Changes bridge, add column → Sync data to my CRM → Lead
2. Choose Create and Manage Record
3. Map fields:
   • First Name → First Name
   • Last Name → Last Name
   • Email → Email
   • Company → Account Name
   • Title → Current Title
   • Type → custom field
   • Lead Source → “Starbridge” or “Starbridge Contact”

Recommended Lead Routing by Use Case

For Use Case 1: New Hires & Promotions at ICP Accounts

Bridge filters:

• Job Change Type = “New Joiner” or “Title Change”
• Buyer List = ICP prospect accounts
• Titles = Target decision-maker roles

Lead routing:

• Assign leads to SDR/BDR team based on territory or account ownership
• Use Lead assignment rules to route by industry, region, or account segment

For Use Case 2a: Departing Champions

• Leads tagged as “Departures” are assigned to CSMs/AMs to review

For Use Case 2b: Champions Moving to New ICP Accounts (Not Recommended for Leads)

• Reps manually review leads from Use Case 1 and check for prior relationship history

Custom object sync: sync dynamic data (RFPs, meetings, purchases)

This scenario covers syncing rows from a Starbridge bridge into a custom CRM object you create, typically used for dynamic data such as RFPs, meeting signals, and purchase data.

1. Create the custom object in your CRM

   Before configuring Starbridge:

   1. Create the custom object in your CRM.
   2. Define the schema and fields.
   3. Create a relationship (association) between the custom object and the Account/Company object.
2. Expose the custom object to Starbridge

   In your CRM integration configuration, ensure Starbridge can read/write the custom object and that all fields you want to populate (including the relationship field linking to the account) are exposed.

3. Add an account lookup column to the bridge

   In your bridge, add a Lookup Record in CRM column for the Account/Company object. If no account is found, you should not create a custom object instance (to avoid orphan records).

4. Add a sync column for the custom object

   Add a Sync Record in CRM column for the custom object and set the sync type to Create and manage.

   • Starbridge creates new records in the custom object.
   • Starbridge can also keep those records up to date over time (enable Keep objects up to date).
5. Map Starbridge fields to the custom object

   Map all relevant Starbridge columns to custom object fields, including the relationship field (Account/Company ID). Recommended best practice: set fields to Overwrite so Starbridge can maintain the object if values change.

6. Add a run condition to prevent orphan custom object records

   Add a run condition that only runs if the account lookup column’s Record ID is not empty. This ensures custom object instances are always associated to a valid account.

HubSpot-specific integration details

Starbridge integrations with both Salesforce and HubSpot generally function the same way. The sections below document key HubSpot-specific considerations.

Normalized fields in HubSpot

HubSpot does not provide differentiated field types for several categories of data that other CRMs (for example, Salesforce) treat distinctly. As a result, Starbridge exposes a Normalized checkbox across a wide range of fields in the sync configuration UI.

Starbridge provides built-in normalizations for:

• Emails
• URLs / domains

Best practice: enable Normalized when referencing a field that can be normalized. This improves match accuracy and keeps lookup/sync behavior consistent.

Managing relations in HubSpot

HubSpot supports flexible relations (many-to-many associations, multiple association labels, multiple related records per object). This introduces important limitations for Starbridge integrations.

Starbridge only supports relations where a given Starbridge-managed object can be associated to at most one other object. This rule applies to all HubSpot custom objects used in Starbridge syncs.

Example: if you create a custom object called Starbridge Meeting and associate it with the HubSpot Company object:

• A Company → many Starbridge Meetings is supported.
• A Starbridge Meeting → at most one Company is required.

To configure this in HubSpot:

• Go to Settings → Objects and select the object you want to set association limits for.
• Choose the Associations tab.
• Select the association pair (for example, Starbridge Meeting ↔ Company).
• Click Create and configure → Configure association limit.
• For each direction, choose “Custom” and set the appropriate limit (in this case, 1 for Starbridge Meeting → Company).

If configured correctly, Starbridge will show a field on the custom object like:

• Company ID (Relation to Company)

To assign or update the relationship during a sync:

1. Select Company ID (Relation to Company) in your Sync column mappings.
2. Map it to your Account lookup column (or other relevant column).
3. Write to this field when creating or updating the custom object record.