Every survey a candidate completed replaced the one before it.
That's how a healthcare staffing company discovered the limitation in their survey platform's native HubSpot integration. It wrote answers to contact properties, and a contact property holds one value. Second survey, first one gone. Third survey, second one gone. A year of candidate feedback reduced to whatever they said most recently, and no error anywhere, because nothing was wrong. The integration was doing exactly what it was built to do.
Then we saw the identical pattern at a video software company, where a content-engagement platform's webhook wrote 30 to 40 fields per session onto the contact. Each session overwrote the last. Engagement history: gone. And a wrinkle on top: that platform's API could only bind to one marketing automation system at a time, so during the migration off their old platform, the integration ran through a webhook workaround, and lead source landed as "Direct Traffic" until someone added the platform as a source value. 200,000 contacts worth of history were deferred past go-live because the native path couldn't carry them.
Ask what happens on the second event
That's the question, and almost no integration review asks it. Native apps are evaluated on whether they connect and whether the fields map. Both of these did. What matters for anything event-shaped (surveys, sessions, downloads, tickets) is what the integration does when the same contact generates a second one. If the answer is "overwrites," you've bought a current-state feed, not a history, and you should know that before you rely on it for reporting.
Where the data lives decides what you can do with it
There are three places event data can live in HubSpot, and the choice decides what you can do with it later.
Contact properties hold current state. Right for "last survey score" or "most recent session." Wrong for anything you'll ever want to count, trend, or roll up.
Custom objects hold history with native reporting. For the staffing client, each survey became a record on a custom object, associated to the candidate, the placement, and the facility, so they could report satisfaction by facility and build toward a candidate health score. More setup, but every record is visible, filterable, and reportable in the tools the team already uses.
Custom events hold timestamped history at volume and can trigger workflows. They're the right answer when the data comes fast (sessions, page-level engagement) and when the main use is triggering action rather than building reports, because reporting on custom events is weaker than on objects.
For the video client we shipped the interim webhook while deciding between objects and events for the full build. That's an honest sequence: stop the bleeding, then choose the model.
To steelman native apps: for most data they're right, and rebuilding a vendor-maintained integration because it doesn't preserve history you'll never use is waste. The test is one question: will I ever need the second value? If yes, the property path is wrong regardless of how well the app connects.
Pull up one native integration you rely on and check what it does on the second event. If you find an overwrite you didn't know about, I'd like to hear which app.
This came out of a client project. The story behind it, and what to check in your own portal, goes to subscribers on Thursdays. Get Thursday's note.
by Perry Nalevka on November 04, 2026
CEO of Penguin Strategies
