Userpilot Salesforce Integration: How to Connect Product Data with Salesforce CRM
The Userpilot Salesforce integration earns its place because of a gap you can see the second an AE, or an Agentforce agent, opens a Salesforce record. That record shows headcount, industry, deal stage, and a last-activity date from three weeks ago. None of it says whether a single person at that account ever finished onboarding.
That gap used to be a reporting inconvenience you could live with. Now that Salesforce runs as an agent-first CRM, where Agentforce reads whatever context sits on the record and takes action on it, the missing product usage signal decides how your reps and your agents spend the quarter.
The scale of that shift is worth a number. Gartner expects 40% of enterprise applications to ship task-specific AI agents by the end of 2026, up from under 5% a year earlier, and every one of those agents acts on whatever the record tells it. Meanwhile, Userpilot’s benchmark across 547 B2B SaaS companies puts average activation at 37.5%, so nearly two-thirds of the signups sitting in your CRM never reached the moment your product was built to deliver.
The Userpilot Salesforce integration closes that gap by streaming real in-app behavior into Salesforce, next to the PQL scoring, health scores, and next-best-action logic that already live there. From here, this guide walks through what syncs, four plays teams run on the synced data, the setup, the constraints that break a first sync, and where your data lands once it arrives.
What the Userpilot Salesforce integration syncs, in both directions
The Userpilot Salesforce integration is properly two-way, and the two directions behave differently enough that it helps to take them one at a time. Inbound first, because outbound depends on it (more on that in the constraints section below). Selected Salesforce user and company properties flow into Userpilot and refresh every five minutes.
Once inside Userpilot, those properties land on the Users and Companies dashboards and in Data Management under the relevant property categories, ready for segmentation and targeting. The properties you’d typically pull in include account status, owner, lifecycle stage, plan type, renewal date, and any custom fields you maintain. A concrete example: pull renewal date in, then target an in-app flow at every account sitting 30 days from renewal.
Outbound is where Userpilot writes back into Salesforce, and it runs on three separate clocks. Custom properties sync every five minutes and send only what changed since the last cycle. Auto and measured properties sync once a day for the Measured period you choose, and user activity streams in real time as events occur.
Here is the whole picture in one place.
| Direction | What moves | Frequency |
|---|---|---|
| Salesforce to Userpilot | Selected user and company properties | Every 5 minutes |
| Userpilot to Salesforce | Custom user and company properties | Every 5 minutes, changed properties only |
| Userpilot to Salesforce | Auto and measured properties | Daily, for the selected Measured period |
| Userpilot to Salesforce | User activity (events) | Real time, as events occur |
The activity stream is the part most teams underestimate, so it is worth being exact about what fires. Every one of these activity types crosses into Salesforce, each carrying the specific events listed next to it. This is the raw material your Salesforce workflows and your agents get to act on.
| Activity type | Events sent |
|---|---|
| Feature tags | Event has occurred |
| Tracked events | Event has occurred |
| Labeled events | Event has occurred |
| Tagged pages | Page viewed |
| Checklists | Seen, Completed, Dismissed |
| Flows | Seen, Completed, Dismissed |
| Mobile content | Seen, Completed, Dismissed |
| NPS | Ask Later, Feedback |
| Surveys | Seen, Submitted, Dismissed |
| Forms | Submitted |
One practical note on access before you plan a rollout. The Userpilot Salesforce integration is included in the Enterprise plan, and it is available as a paid add-on for Growth plans, so a Growth team can run it without moving up a tier.
Four plays: Product, sales, and CS teams run on synced usage data
Synced data only matters if someone does something different with it, so here are the four plays I see teams run on the Userpilot Salesforce integration. Each one puts the integration to work rather than pointing you to a Salesforce feature you already own.
1. Work real PQLs instead of every signup
When usage properties sit on the record, an AE opens an account and sees activation status and feature adoption before they dial. That matters because of the activation gap from the intro: most signups never reach the moment the product was built to deliver, so treating every signup as a lead wastes the quarter. The fix is to segment the accounts that show real product usage and work on those first.
Kyle Poyar, co-founder of Tremont and author of the Growth Unhinged newsletter, argues that a single PQL definition is the mistake, since different accounts need different next steps. In his words:
“Savvy operators carve out at least three buckets of PQLs.”
Those three buckets map cleanly onto who gets which play, and the synced usage data is what lets you tell them apart on the record:
- Hand-raiser accounts that asked for sales directly.
- Usage-based accounts that crossed an adoption threshold can be seen in the synced events.
- Needs-help accounts that are stuck short of value and need a nudge before they churn.
2. Trigger Salesforce automations off real product milestones
Because activity streams are in real time, a product event can fire a Salesforce workflow the moment it happens rather than the next morning. A completed onboarding checklist, an activation milestone reached, or a feature adopted each arrives in Salesforce as one of the activity types from the table above (checklists, tracked events, feature tags), and each can trigger a workflow, an alert, or a follow-up task. That turns “the account went quiet” into a task on someone’s list before the renewal call.
3. Personalize in-app experiences with CRM context
The inbound direction of the Userpilot Salesforce integration is what makes this play possible, since account status, lifecycle stage, plan type, and renewal date all land in Userpilot, ready to be targeted against. You can point a flow, a checklist, or a campaign at accounts based on where they sit in the CRM. A renewal-window flow, a plan-specific onboarding path, and a lifecycle-stage nudge all become straightforward once the CRM context is inside Userpilot.
4. Give product, sales, and CS a customer view
The fourth play is the sum of the other three: behavioral data from Userpilot and CRM data in Salesforce sitting on the same record, feeding health scoring, lifecycle messaging, and expansion discovery. This is also where Lia does useful work. Lia, Userpilot’s AI agent, surfaces the adoption or churn-risk signal inside Userpilot, and that same behavioral signal streams into Salesforce for a rep or an Agentforce agent to act on.
One caveat is worth stating plainly, since it affects what you can promise your team. Lia is in progressive rollout, and the exact capabilities available to you vary by plan tier, so confirm what your tier includes before you build a play that depends on it.
Setting up the Userpilot Salesforce integration in six steps
Setting up the Userpilot Salesforce integration is a short sequence, but the order matters more than it looks, so follow the steps as listed.
- Connect and authenticate: Open the Integrations page from the Settings icon in the navigation header, click the Salesforce tile, and authenticate with the account you want to connect. That handshake is what lets the two systems exchange data at all.
Authenticate with the Salesforce account. - Review the connection overview: Before you touch anything live, toggle “Send and receive staging data only” to validate mappings and property syncs without writing to real Salesforce records. It is worth doing on a first setup, because you catch a bad mapping while it still costs nothing.
- Map your objects and matching field: Choose which Salesforce objects to map Userpilot Users and Companies to (Leads, Contacts, Accounts), then choose the Userpilot property and Salesforce field used to match records. The values have to be identical in both systems, so the docs recommend email for user-level mapping, while companies can map on any other unique identifier that stays consistent across both systems.
Map your objects and matching field. - Select the Salesforce-to-Userpilot properties: Choose the inbound properties you want to sync into Userpilot. This step populates the account status, lifecycle stage, plan type, and renewal date you saw in Play Three.
Select the Salesforce-to-Userpilot properties. - Select the Userpilot-to-Salesforce data: Choose the custom properties, the auto and measured properties, and the activity to send out. Inbound has to have run first, which is the constraint that catches the most people, and the next section explains why.
Select the Userpilot-to-Salesforce data. - Review, test, then sync: Testing gives you a read-only preview of how selected users will map and flags any failures, and nothing is changed or synced while a test runs. You can trigger a manual sync at any time, and enabling sync notifications will alert you to a failure instead of leaving you to spot it later.
Review, test, then sync.The constraints that quietly break a first sync
This is the section I wish every new setup would read first, because these four constraints cause almost every “why did nothing happen” support ticket on the Userpilot Salesforce integration. I have ordered them by how much time they cost, worst first.
Outbound returns zero records until inbound has run. Before you can run an outbound sync from Userpilot to Salesforce, you have to complete an inbound sync from Salesforce to Userpilot, because inbound is what populates the __salesforce__object_type and __salesforce__user_id / __salesforce__company_id fields that outbound depends on. Without those fields the outbound sync processes zero records, so if you take one thing from this section, take this one.
There is no historical backfill. The integration does not sync past events, so only new events fire once the sync is enabled, and any usage history you want in Salesforce starts accumulating the day you switch it on. That alone is a solid reason to turn it on before you think you need it, so the history is already there when a renewal conversation makes you reach for it.
Users have to exist in both systems already. Userpilot does not create new users in Salesforce, so a user who is not already in Salesforce syncs nothing at all. This one surprises people, because the natural assumption is that syncing will also create missing records, and it does not.
Field types have to match the data. A measured property written as seconds needs a Number field, a date needs a Date field, and a datetime needs a DateTime field stored in UTC. Get the format right on the Salesforce side and the values land clean, as shown below.
| Userpilot data | Format | Salesforce field type |
|---|---|---|
| Measured properties (e.g. time spent on application) | Integer, total seconds. 9000 seconds = 150 minutes = 2.5 hours. Minutes = ÷60, hours = ÷3600, days = ÷86400 | Number |
| Date (e.g. signup_date) | YYYY-MM-DD, e.g. 2024-01-15 | Date |
| DateTime (e.g. last_seen, created_at) | YYYY-MM-DDTHH:mm:ssZ in UTC, e.g. 2024-01-15T10:30:00Z. Salesforce stores datetime in UTC | DateTime |
The good news comes last, and it removes a chore that older integrations forced on you. On version 2 of the integration, you do not re-run mappings by hand, so if a mapped value changes in Salesforce, say a contact’s email is updated after you mapped on email, the poll strategy detects the change on the next poll cycle and re-maps automatically. Real-time sync fires in three cases: when a user triggers an event you selected in the settings, when a new record is created in Salesforce, or when a mapped record property is updated there.
Where your Userpilot data lives once it’s inside Salesforce
Once the Userpilot Salesforce integration is running, the data has to live somewhere, and knowing where saves you a confused hour hunting for events that synced fine.
Userpilot events are stored under the Userpilot Events object. To find it, go to your Salesforce Dashboard, click the App Launcher (the grid icon, top left), search “Userpilot Events,” and open the object.
That object holds everything sent from Userpilot, including flow completions, button clicks, and other user interactions. Alongside it sit five custom objects that carry the richer feedback and interaction data: Userpilot Interactions, Userpilot Nps, Userpilot Forms, Userpilot SurveyQuestions, and Userpilot Surveys.
Here is the part that trips everyone up: Salesforce doesn’t display custom objects by default, so they exist and stay invisible until you add them. To make them visible:
- Go to Setup.
- Search Tabs in the left menu.
- Open the Custom Object Tabs section.
- Click New under Custom Object Tabs.
- Add each Userpilot custom object individually.
To choose which fields display on one of those objects, search for the custom object (for example, Userpilot Interactions), open it, select All from the dropdown, click the gear icon, choose Select fields to display, move the fields you want from the left list to the right with the arrow, and save.
If you want those objects to appear directly on a Contact, Lead, or Account record, go to Setup → Object Manager, select the object you want to edit, open Page Layouts, then Related Lists, and drag each Userpilot object into the Related Lists section. Use the wrench icon next to each related list to choose which properties appear for that object.
Reporting is the payoff for all that setup. To create a report:
- Go to Reports and click New Report.
- Select Userpilot Events as the data source.
- Add filters, group data by user attributes, and visualize the trends you want to track.
- Save and schedule the report to monitor engagement over time without rebuilding it each week.
Give your reps and your agents the signal they’ve been missing
Every Salesforce record already knows the industry, the headcount, and the deal stage, and none of that tells anyone whether the account is going anywhere. The Userpilot Salesforce integration adds the one thing the record was missing, which is what people and agents are doing inside your product, and it puts that signal exactly where reps, health scores, and Agentforce already work. That shifts every decision from an account’s profile on paper to its real behavior in the product.
If you want to see the sync, the mappings, and the plays running on your own Salesforce setup, book a Userpilot demo, and we will walk through it together.
About the author
