Integration Platforms
Part of Workflow data synchronisation
One-way versus two-way record synchronisation
Choose a record sync direction from valid edit paths, then check field support, matching and conflict settings in the intended connector.
Use one-way synchronisation when one application should supply a shared value and the other should receive it. Use two-way synchronisation when valid edits can start in both applications and the integration can resolve competing changes. Decide per record type and, where the connector permits it, per field.
Follow the permitted edit paths
Take a customer account that appears in sales and service applications. If sales owns customer category and service only reads it, category should move one way. If staff may legitimately change a phone number in either place, that field needs two-way handling or a clear route for submitting edits to one authority.
| Question | One-way design | Two-way design |
|---|---|---|
| Who edits the shared value? | One named authority | Both sides have a valid edit path |
| What if the receiving side changes it? | Reject, ignore or route the edit to the authority under an explicit rule | Detect and resolve it |
| What if both sides change it during an outage? | Check the authoritative value and deletion rule | Compare both changes before applying either |
| What confirms success? | The destination reflects permitted source changes | Both valid edit paths produce the agreed state |
These are design choices, not connector promises. A two-way record setting does not mean every field is writable both ways.
One-way versus two-way design decisions
- Who edits the shared value?One-way: one named authority. Two-way: both sides have a valid edit path.
- Receiving-side editsOne-way: reject, ignore or route the edit to the authority under an explicit rule. Two-way: detect and resolve it.
- Competing changes during an outageOne-way: check the authoritative value and deletion rule. Two-way: compare both changes before applying either.
- What confirms success?One-way: the destination reflects permitted source changes. Two-way: both valid edit paths produce the agreed state.
Check the connector’s actual limits
HubSpot data sync can be configured for one-way or two-way sync. Its data conflict resolution setting lets you prioritise an app when it is unclear which app has the most up-to-date information.
HubSpot also documents fields that can map only one way because the connected app’s API or field is read-only. Creating and customising field mappings requires Data Hub Starter, Professional or Enterprise.
Check which records enter the sync and how they are matched. HubSpot’s matching options differ by app and object; once records are paired, their IDs maintain the live sync.
Connector limits to verify
- HubSpot data sync can be configured for one-way or two-way sync.
- Data conflict resolution can prioritise an app when it is unclear which app has the most up-to-date information.
- Some fields can map only one way because the connected app’s API or field is read-only.
- Creating and customising field mappings requires Data Hub Starter, Professional or Enterprise.
- Matching options differ by app and object; once records are paired, their IDs maintain the live sync.
Record the field rule
For each shared field, record the authorised editor, direction, treatment of blank or absent values, and conflict rule. If a connector cannot enforce the required authority, narrow the mapped fields or choose an integration route that can. Do not use “latest update wins” for a value whose business meaning requires a named authority or review.
Before enabling writes, compare expected and actual records for an edit from each allowed side, a receiving-side edit that should not propagate, and competing edits to a two-way field. Inspect values and paired IDs as well as sync status.
Field rule to record for each shared field
- Authorised editor
- Sync direction
- Treatment of blank or absent values
- Conflict rule
