> ## Documentation Index > Fetch the complete documentation index at: https://docs.tented.ai/llms.txt > Use this file to discover all available pages before exploring further. # Contact data sync > How Tented keeps contacts in sync with a connected CRM: what comes in, what goes back, how duplicates and conflicts are handled, and what disconnecting removes Some integrations can keep the contacts in **People** in sync with the connected app. HubSpot is the first; the behaviour described here is the same for every integration that offers it. ## Three modes Every integration with contact sync asks the same question during setup: | Mode | What it does | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Don't sync contacts** | Nothing changes in People. | | **Import** | The app's contacts appear in People and are kept up to date about every 15 minutes. Tented never writes back. | | **Two-way** | Changes flow both ways: the app's edits come in, and Tented edits and new Tented contacts go back. When the sync is limited to one of the app's lists, only contacts from that list and contacts created in Tented go back; contacts that came from a list import or another integration stay in Tented. | ## Limiting the sync to a list You can limit the sync to one of the app's lists. Contacts in that list come in and, with two-way sync, go back. A contact that leaves the list stops syncing in both directions from its next change onward, and picks up again when it rejoins, including any changes made in the app while it was out. Contacts created in Tented are the one exception: once Tented has created them in the app they stay in step whether or not they are in the list, because that pairing exists because of Tented, not the list. ## Which fields sync **Standard fields** (name, email, company, and so on) are matched to Tented's fields for you. For each, choose what happens when a Tented contact already has a value: **Overwrite** or **Do Nothing**, the same choice a list import offers. Email and phone are the match keys that pair a contact with an app record the first time; after that they follow the same rules as every other field (see **Duplicates and conflicts**), except that an email or phone emptied in the app never empties Tented's copy. With two-way sync the rule works the same way in the other direction: a **Do Nothing** field is only ever filled in on the app's side, never replaced, so each side keeps its own value. **App fields** are any other properties you add. They appear as their own group on each contact (for example **HubSpot fields**) and are marked as managed by that integration in People settings. Each is either **Read-only** (the app owns the value) or, with two-way sync, **Editable** (edits in Tented go back to the app). Types Tented does not have, such as multiple-choice or calculated properties, come in as read-only text; file and rich-text properties cannot be synced. Each app field uses one of your workspace's custom-field slots. The setup step shows how many are left and will not save a mapping that does not fit. ## Unsubscribes The app's opt-out flag is mapped to Tented's **Unsubscribed** by default and only ever unsubscribes a contact. A contact who unsubscribed in Tented is never re-subscribed by the app. With two-way sync, Tented unsubscribes are written to a dedicated property in the app. ## Duplicates and conflicts Contacts are matched on email, then phone. If a matching contact already exists in Tented, you choose whether to update it using the field rules above or skip it. Once a contact is linked to an app record, that link is what identifies it: an email or phone changed in the app updates the same Tented contact rather than creating another, and an email or phone changed in Tented is kept (and, with two-way sync, sent to the app) unless the app changed it too. Each sync applies only the fields the app actually changed since the last one, so an edit made in Tented is kept when the app changes a different field. If the same field changed on both sides between two syncs, the app's value wins. A field emptied in the app is emptied in Tented too, unless its rule is **Do Nothing**. Two-way sync sends only the fields that changed in Tented. Phone numbers keep the app's own formatting until the number itself is changed in Tented. For a field that is a dropdown in the app, such as a lifecycle stage, Tented sends the matching option; a value the app has no option for is left out, and the rest of the contact still goes. If the app then fills that field with its own default (HubSpot sets a new contact's lifecycle stage to Lead), the default only fills the field in Tented when it is empty; it never replaces the Tented value. If the app refuses a contact outright, the integration card shows how many contacts were not accepted and the reason for the latest one. A refused contact is tried again the next time it changes in Tented. ## The first sync The first sync reads every contact in the app (or the list you chose) and imports them in one run, shown in **People → Past imports** with counts. There is no size limit: an account with millions of contacts is read in pages over a few hours, prepared and imported in the background in bounded batches so the rest of your workspace (and other workspaces) stay responsive, and picked up where it left off if anything interrupts it. A very large account can take a day to finish. Later syncs only fetch what changed. If part of the first sync fails, it is tried again automatically; if it keeps failing, the integration card says so and saving the sync settings starts it over. Contacts created by a sync show the app's name as their source. ## Disconnecting Disconnecting removes the app's field group and its values from every contact. The contacts, and everything in their standard fields, stay. Lists or flows whose rules, triggers or steps used those fields keep running, with those conditions matching nobody, and show **Needs attention** (in the lists table, the flows table and the flow editor) until they are changed. The confirmation names them before you disconnect. Removing a field from the mapping later works the same way for that one field. A dynamic list whose rule used a removed HubSpot field, marked Needs attention in the lists table. If you reconnect the same account, the fields and links from before are kept. See [Connecting HubSpot](/integrations/connecting-hubspot#syncing-contact-data-optional) for the HubSpot specifics.