Stop a flow creating duplicates

<h2>Three causes, three fixes</h2><p>Duplicate records almost always trace back to one of three things. The flow was built with a create action when it needed a create or update action. The trigger reads the same record more than once because nothing marks it as handled. Or two flows write to the same destination without knowing about each other.</p><p>Work out which one you have before changing anything, because the fixes do not overlap and applying the wrong one leaves the problem in place with a more complicated flow around it.</p><h2>Match on a unique field</h2><p>The cleanest fix. Instead of always creating, tell the action which field identifies a record, and Syncline updates the match when it finds one.</p><ol><li><strong>Open the action step</strong> and switch it from <em>Create</em> to <em>Create or update</em> where the app offers both.</li><li><strong>Choose the matching field.</strong> Pick something that is genuinely unique and stable, which usually means an email address, an order number or an ID from the source app.</li><li><strong>Map that field on both sides.</strong> The value has to be written into the destination as well as compared against it, or the second run has nothing to find.</li><li><strong>Decide what an update overwrites.</strong> Each mapped field has an update rule: always write, write only when empty, or never write after creation. Notes and owner fields are usually set to never.</li><li><strong>Test twice with the same sample.</strong> The first run creates, the second must update. If the second creates as well, the matching field is not being written.</li></ol><table><thead><tr><th>App</th><th>Field to match on</th><th>Worth knowing</th></tr></thead><tbody><tr><td>HubSpot</td><td>Email</td><td>Native deduplication, matches even on case differences</td></tr><tr><td>Notion</td><td>A text property holding the source ID</td><td>Add a hidden property rather than reusing the title</td></tr><tr><td>Airtable</td><td>Any field, commonly Record ID from the source</td><td>Index it in a view so lookups stay fast</td></tr><tr><td>Trello</td><td>A line in the card description</td><td>Trello has no custom key, so we search the description</td></tr><tr><td>Stripe</td><td>Customer email or metadata key</td><td>Metadata is the more reliable of the two</td></tr></tbody></table><blockquote><p>Note: matching costs one extra read per run and that read does not count as a task. There is no billing reason to avoid it, so turn it on for anything creating people, companies or orders.</p></blockquote><h2>Stop the trigger reading twice</h2><p>Email is the usual offender. A search based trigger keeps returning the same message until something about that message changes. Add an <em>Apply label</em> action at the end of the flow and exclude that label in the trigger search, which turns the mailbox into a one way queue.</p><p>The same pattern works elsewhere. Move a card out of the watched list, flip a checkbox in the database, or set a processed date. Any change that makes the record stop matching the trigger will do.</p><h3>Two flows, one destination</h3><p>This one is a conversation rather than a setting. Open both flows, compare the triggers, and check whether a record can satisfy both. If it can, either narrow one filter or merge the two flows into one with a branch. The run history helps here: each row names the flow that wrote it, so a duplicated record shows you exactly which pair collided.</p>