Flow Strategy for Auto-Merge
See how to build a custom Flow strategy that controls master record selection and automatic merging of duplicate records. The video explains when to use Flow strategies, walks through building a Flow for master record selection, configuring automatic merge triggers, and handling edge cases and error scenarios.
What You'll Learn
- Decide when a Flow-based master record strategy is the right choice over standard strategies
- Create an autolaunched Flow with the required InputRecords collection variable
- Return the chosen master record ID through the MasterRecordId output variable
- Wire the Flow into an Auto-Merge rule as the Master Record Strategy
- Test the Flow safely on a small set of duplicates before turning on automation
Key Takeaways
- Use Flow strategies only when standard strategies (Most Recent, Most Complete, etc.) cannot express your logic
- The InputRecords and MasterRecordId variable names must match exactly — the app uses them as the contract
- Always activate the Flow before assigning it in Auto-Merge Setup
- Flows can call out to external systems, but every callout adds latency to every merge
Frequently Asked Questions
When should I prefer a Flow strategy over a standard strategy?
Choose Flow only when standard strategies (Most Recent, Most Complete, Highest by Field, Lowest by Field) genuinely cannot express your master selection logic. Standard strategies are easier to maintain and far less prone to runtime errors.
What happens if my Flow throws an error during a merge?
The merge for that duplicate group is skipped and logged. Other duplicate groups continue to process. Always test the Flow on a small set of records before enabling it for high-volume rules.
Can I use the same Flow for multiple matching rules?
Yes, but the Flow must be compatible with every object the rules operate on. If you have rules across Accounts, Contacts, and Leads, you typically need a separate Flow per object because InputRecords is typed.
Why must the variable names be exactly InputRecords and MasterRecordId?
The No Duplicates engine looks up these variables by API name when invoking the Flow. Renaming them breaks the contract and the Flow will fail to receive input or return the master.


