What a trail pushes to your CRM
The record types a trail can push, how rows are matched, what happens to each row, who owns the new records, and when a push goes out on its own.
By Operelio team · Updated September 2026
On this page8
Where it pushes
A trail pushes to one connected CRM, set on the push tile at the end of the chain. Your workspace can hold one connection per CRM. Each trail pushes one type of record, and rows are matched to records already in the CRM, as the table shows.
| CRM | Record types | Matched on |
|---|---|---|
| HubSpot | Contacts | Email address |
| HubSpot | Companies | Company domain name or website, then name |
| Salesforce | Contacts or leads | Email address |
| Salesforce | Accounts | Website, then name |
| Pipedrive | People | Email address |
| Pipedrive | Organizations | Website, then name |
A person row with no email address, or a company row with neither a website nor a name, is never created, whatever the settings below say.
What happens to each row
The push tile asks three questions about each row. The last only appears when matched records are updated.
| Question | Answers |
|---|---|
| A row that matches no record | Create a new one, or Skip the row |
| A row that matches a record already there | Update their record, or Leave them alone |
| When the CRM already has a value | Keep what the CRM has, so the file only fills in blanks, or Replace it with the file's value |
Replacing values is the one thing a push does that you cannot undo. A run that would replace a value always waits for your approval, whatever the trail's push policy says.
Who owns the records
You choose who owns the records the trail sends:
| Choice | What happens |
|---|---|
| One person | Every record the trail creates goes to the same owner. |
| Share them out between people | Every row of the file is dealt out to the people you pick, in the order you pick them, starting from the top of the list on each run. If the rows do not divide evenly, the first people get one extra. Rows that are skipped or matched still take their turn, so the new records may not split evenly. |
| Use a column in the file | Each row goes to the rep whose email address is in that column. A row that names someone your CRM does not have holds the push. A blank cell sends no owner, the same as Nobody. |
| Nobody | No owner is sent. In HubSpot the records arrive unassigned. Salesforce and Pipedrive give them their default owner. |
The owner goes to records the trail updates too. With Keep what the CRM has, a record already there keeps its owner, or gets this one if it has none. With Replace it with the file's value, it gets this owner. If that changes an owner already set, it counts as replacing a value, so the push waits for your approval.
Notes
Attach a note adds a column from the file as a note on each HubSpot contact the push creates. A row with a blank cell gets no note. On other CRMs and record types the setting adds nothing.
What the formatter sends
Before a trail can switch on, an admin opens the formatter tile on the Sandbox tab, checks what it will send, and clicks Confirm this is what we send. Swapping the mapping, changing the CRM or the record type, or reconnecting the CRM clears this. A trail that is on stops, and someone has to confirm again and switch it back on. The one exception is signing in again to the same CRM account without disconnecting it first. That still clears the review, but the trail keeps running. If your CRM's fields change after a review, the formatter tile says so and offers Confirm again, and the trail keeps running.
When a push goes out on its own
The push policy decides what happens to a run with nothing flagged. Anything the safety checks or Bridgeant flag waits for you either way.
| Policy | What happens |
|---|---|
| Hold every push for review | Nothing reaches your CRM until someone approves it. A trail you start from scratch or from a workflow begins here unless your workspace default says otherwise. Templates set their own policy, and three start on Send the clean ones. A copy keeps the policy of the trail it was copied from. |
| Send the clean ones | A run with nothing to flag pushes on its own. Everything else still waits. |
Set the policy on the push tile's When it sends tab. The workspace default, under Trails in Settings, only applies to trails started from scratch or from a workflow after you change it.
At push time
Just before it pushes, the trail checks the file against your CRM as it is then. It counts what it would create, update or skip, and what your CRM would refuse, and runs the safety checks on those counts.
If there is nothing to send, for example because every row is already up to date, the run finishes without pushing. If your CRM would refuse every row, the run fails.
If only part of a push lands, the run stops and says how many rows did not go. The run's page lists them, and Download the list gives you every one. You cannot send just those rows again. An admin can edit a step before the push to send the whole file through again, and so can everyone if the workspace allows it. Rows that match a record already in your CRM then follow the trail's push settings.
Related
Frequently asked questions
Can one trail push to two CRMs?
No. A trail pushes to one CRM. Make a second trail for the other one.
Will a trail overwrite what is already in my CRM?
Only if you choose Replace it with the file's value, and then every run that would replace a value waits for your approval first.
Does a trail create duplicates?
Rows are matched on email address for people, and on website or name for companies, so a row that matches a record of the same type already in your CRM is never created again. Rows repeated in one file are sent once.
Ready to get started?
Upload a file and run your first transformation. Free, no credit card required.