Event signal:user.signup| Destination:HubSpot| Use case:User Signup Fan-Out| Typical setup:~15 minutes
Workflow outcome
The workflow starts with user.signup and ends with HubSpot holding the lifecycle fields and list state that growth or sales teams actually work from.
The result is a cleaner signup architecture: your product emits one event, Meshes handles the destination-specific delivery, and HubSpot gets the fields it needs to kick off downstream automation.
Why teams care
Signup is one of the most common SaaS fan-out events, and it is usually the first place teams start hardcoding CRM updates into application code.
If HubSpot properties arrive late or inconsistently, lifecycle campaigns, attribution reporting, and sales handoff all start from stale data.
This is exactly the kind of workflow that looks easy until you add retries, mapping changes, customer-specific routing, and the need to debug one missed update three weeks later.
What it depends on
These pages stay focused on the workflow outcome, but the setup still needs the right workspace, destination connection, and event path underneath.
Authorize HubSpot in Meshes and confirm the contact properties or lists you want already exist.
Read moreYour app should be able to emit user.signup with the fields HubSpot should receive.
Decide which signup fields belong in HubSpot properties and whether you also want list membership as a separate rule.
The source event
HubSpot is useful when the event carries the fields your lifecycle and GTM teams actually segment on. That usually means identity fields plus the acquisition and plan fields you would otherwise try to sync later.
Event payload
user.signup{
"user_id": "usr_2048",
"email": "alex@northstar.io",
"first_name": "Alex",
"last_name": "Nguyen",
"plan": "starter",
"source": "website",
"utm_source": "google_ads"
}What matters most
HubSpot uses email as the core contact identifier for this workflow.
first_name + last_name
Lets your CRM and downstream messaging read like customer communication instead of a raw lead record.
plan
Useful for lifecycle branching, sales qualification, and signup segmentation.
source
Keeps the signup channel attached to the contact record from day one.
utm_source
Preserves campaign context before it disappears into reporting cleanup work later.
Field mapping view
| Event field | Destination target | Why it matters |
|---|---|---|
| HubSpot contact email | Used to identify or update the right contact record. | |
| first_name | firstname | Keeps lifecycle and sales views readable. |
| last_name | lastname | Completes the contact record for downstream usage. |
| plan | Plan tier property | Supports lifecycle branching or lead qualification in HubSpot. |
| source | Signup source property | Captures where the user came from without a later backfill. |
| utm_source | Campaign attribution property | Preserves ad or campaign context for reporting and nurture. |
The destination connection
In your Meshes workspace, create the HubSpot connection that should receive user.signup and confirm the contact properties or lists already exist. That gives you the targets you need before you create the Meshes rules that turn signup into CRM state.
Where Meshes matters
Most teams do not need another destination. They need the destination to stay in sync without embedding its delivery quirks, retries, and mapping logic into the product code path.
In Meshes, the common setup is one user.signup rule that updates contact properties and, if needed, a second rule that adds the same contact to a lifecycle list. That keeps the logic explicit while still letting your app emit only one event.
A sample event
This is the part teams like: the source event stays readable and product-shaped while Meshes owns the destination-facing complexity.
TypeScript example
import MeshesEventsClient from '@mesheshq/events';
const events = new MeshesEventsClient(process.env.WORKSPACE_PUBLISHABLE_KEY!);
await events.emit({
event: 'user.signup',
payload: {
user_id: 'usr_2048',
email: 'alex@northstar.io',
first_name: 'Alex',
last_name: 'Nguyen',
plan: 'starter',
source: 'website',
utm_source: 'google_ads',
},
});Destination outcome
Use Send Test Event in Meshes or send one representative signup event, then inspect the contact in HubSpot. You should see the mapped properties updated immediately, and any list-based workflow should have the contact in the right audience.
Operational visibility
The difference between a nice demo and a usable product workflow is whether you can see what happened when the destination is slow, misconfigured, or unavailable.
In Meshes
user.signup event appears in Meshes and the HubSpot rule is matched.Why teams buy Meshes
What's next
Use Case
See the larger pattern of routing signup to CRM, lifecycle email, support, and internal alerts.
Open linkIntegration
See the HubSpot connection flow, supported actions, and event result review.
Open linkDocs
Review how actions, rules, and field mappings fit together for destination delivery.
Open linkCompare
See what it costs to keep CRM update logic inside your signup code path.
Open linkGuide
Use the same signup event to start lifecycle email from the right audience in Mailchimp.
Open linkGuide
Carry the lifecycle story forward by routing later plan changes into Salesforce.
Open linkuser.signup once, let Meshes update the CRM fields and lists, and stop embedding HubSpot delivery logic in your app.