Push back to HubSpot
Writing Auron's output onto a company or deal, with an approver seeing the payload first.
Writing to HubSpot is a step you add to an automation, called Push to HubSpot. It takes the record the automation is running on and writes its fields onto the matching HubSpot contact, company or deal.
Because it runs inside an automation, it composes with everything else: a workflow can end a meeting, summarize it, write the summary onto the record, and then push that record to HubSpot, all in one chain.
Every write is approved first
The step always pauses for approval. This is not a setting you can turn off.
When the step is reached, Auron works out exactly what it would send and posts an approval card to the approvers you nominated. The card lists the object it will write to and every property and value, so an approver is reviewing the actual payload rather than a promise about one. Approving sends it; rejecting ends the run without writing; no answer inside the timeout also ends the run without writing.
Approvers get the card in their feed and a notification on their phone, and respond from either.
Configuring the step
| Setting | What it does |
|---|---|
| HubSpot sync | Which sync's connection and mapping the push uses |
| Approvers | Who can approve the write. At least one is required |
| Match property | How to find the object, when the record did not come from HubSpot |
| Extra properties | Additional properties to send, as JSON |
| Approval timeout | How long to wait for an answer. Defaults to 24 hours |
The sync supplies the mapping, read in the other direction: the columns it pulls in are the properties it writes out. One mapping describes how an entity and a HubSpot object correspond, so the two directions cannot drift apart. Properties HubSpot calculates itself, such as creation and modification dates, are skipped rather than being sent and rejected.
The match property is only needed for records that did not come from HubSpot. A record a sync created already points at its HubSpot object, and Auron writes to it by id, which cannot go stale or match the wrong object. For anything else — a record your team created in Auron — the step needs a property marked unique in HubSpot, such as domain, and finds or creates the object by matching on it.
Extra properties let a workflow set something the sync does not mirror, for example moving a deal stage: {"dealstage": "contractsent"}. They are applied on top of the mapped columns, so they win where the two overlap.
What the record has to look like
Two conditions have to hold, and both produce a clear error rather than a silent no-op.
The record has to belong to the same entity the chosen sync is mapped to. And it has to have a value in at least one mapped column — a record with nothing to say produces no write.
Empty fields are skipped rather than sent as blanks, so a push never clears a HubSpot field just because Auron has no value for it.
Changes do not bounce back
An outbound write changes the object in HubSpot, which changes its modification date, which is exactly what the inbound sync watches. Left alone, every write would come back as an inbound change and the two directions could push each other back and forth indefinitely.
Auron records what it wrote and when, and the next sync run recognizes its own write and skips it. Real edits made by a person in HubSpot come through as normal.
Where this is managed
The step is added inside an automation, under Automations. The sync it borrows its mapping from is configured under HubSpot, described in Create a sync. Approval cards arrive in the approver's feed and on their phone.