How to Mass-Update HubSpot Records (2026) | Clay
Updating a thousand HubSpot records is the easy part. Not creating a thousand duplicates, and not overwriting data a rep already trusts, is the hard part.
A mass update is a bulk write to your system of record, and a bulk write goes wrong in bulk. Point it at the wrong action and you spawn a second copy of every record. Map a blank cell onto a good value and you wipe fields nobody asked you to touch. Skip the test and you find out in production. The teams that do this safely treat it like a release. They pull the records, prepare the values, update by record ID, protect fields they do not own, and test first. This is how to run a mass update in HubSpot without the cleanup afterward.
Step 1: Pull the exact records you want to update into Clay
Start by importing only the records you intend to change, not your whole portal. The narrower the set, the less you risk.
Use the Import objects from HubSpot source in Clay. Pick the object type (contacts, companies, or deals) and, ideally, a specific HubSpot list so you pull a defined segment instead of everything. Two toggles matter here: leave read-only properties off unless you need calculated fields, and consider excluding empty properties to keep the table clean. The import brings each record's HubSpot Object ID along with it, which is the key the whole update depends on later.
Step 2: Prepare the new values before you touch HubSpot
Do all the enrichment and cleanup in Clay first, where a mistake costs nothing. HubSpot should only ever see finished values.
Enrich the gaps, normalize the formats, and run any AI research in the Clay table. Compute only the fields you actually plan to write back. A column you do not intend to update should never get mapped to HubSpot. The cleanest tables hold the record ID, the few fields being changed, and nothing else.
Step 3: Choose the write action, because that is what prevents duplicates
The action you pick decides whether a record updates in place or spawns a copy. This is the single most important choice in the whole job.
Because you imported records carrying their HubSpot Object ID, the correct action is Update object, which keys on that Object ID and writes to the exact existing record. It does not create anything, so there is nothing to duplicate. Two other paths exist for the other cases: Create object is for net-new rows only (HubSpot dedupes contacts by email and companies by domain, but differing values still create copies, so reserve it for records that truly do not exist yet); and when your rows hold only an email or domain, Lookup the object first to resolve its Object ID, then update in place.
| Action | Use When | Duplicates | Description |
|---|---|---|---|
| Update object | You are updating records you imported | No duplicate | Writes to the existing record in place. |
| Create object | For net-new records only | Yes | Creates a new record if the ID does not exist. |
| Lookup, then Update | Rows hold only email or domain | No duplicate | Resolves the ID and updates in place. |
Step 4: Protect the fields you don't own
A mass update can quietly erase good data. The danger is a blank cell mapped onto a field that already had a value.
HubSpot does not ask whether you meant to send an empty value. If a blank Clay column is mapped to a populated HubSpot property, the update writes the blank, and the old value is gone. Two habits prevent it. Map only the columns you are deliberately changing, and add a conditional run so the update fires only when the new value is present. A row with nothing to add then skips the write instead of overwriting what a rep already trusted.
| Field | Action |
|---|---|
| Job title | Update if present |
| Industry | Update if present |
| Employee count | Update if present |
| Lifecycle stage | Blank skipped, value kept |
| Deal notes (rep-owned) | Protected · excluded from write |
A conditional run plus a protected-field exclusion turns a risky bulk write safe: a blank Clay cell never overwrites a good HubSpot value, and rep-owned fields are never touched.
Step 5: Test on a small slice before the full run
Never let the first time a mass update runs be the time it runs on everything. Prove it on a handful of records.
Filter your table to 10 to 25 records and run the full write against them. If you have a HubSpot sandbox, point Clay's connection there so production is untouched while you check. Open the affected records in HubSpot and confirm three things: the right field changed, nothing else moved, and no duplicate appeared. Only after a clean test do you widen the filter to the whole set.
Step 6: Run it, then put recurring updates on a schedule
A one-time mass update fixes today. The records start decaying again tomorrow, so the real win is making the update recurring.
Turn on auto-update for the write so the table re-runs as records change, and HubSpot stays current without anyone re-importing a CSV. Set the cadence to match how fast your data moves; a daily refresh keeps most fields honest. The same conditional run that protected your fields in the one-time write keeps protecting them on every scheduled pass.
Common failure modes, and how to avoid them
Most mass-update messes trace back to four mistakes.
- Using Create when you meant Update: A Create action run across records that already exist copies every record instead of changing it. For records you imported, use Update object keyed on the HubSpot Object ID.
- Mapping columns you did not mean to write: A blank or stale Clay value clobbers a good HubSpot field. Map only the columns you are deliberately changing, and run conditionally on a present value.
- Running on everything before testing on a slice: An error scales to your whole portal. Run the full write against 10 to 25 records, or a sandbox, and confirm the result before you widen the filter.
- Treating the update as one-and-done: The records you just cleaned start rotting the next day. Turn on auto-update so the same protected write keeps HubSpot current on a schedule.