#Flow159 diskutieren mit

The recommended approach is an After-Save (Actions and Related Records) Record-Triggered Flow.

• Before-Save Flow: Use it when you only need to update fields on the triggering Account record itself. It’s faster because Salesforce can update the record before committing it to the database, but it is not intended for updating related Contact records.
• After-Save Flow: Required when you need to perform actions on related records, such as updating Contacts when the Account’s Billing City changes. The Account must be saved first, then the Flow can update its related Contacts.

For 500+ Contacts

For bulk safety, avoid doing a Get Records + Loop + Update Records pattern if you can update the related Contacts directly.

A good design is:

1. Trigger when Account is updated.
2. Add a condition so the Flow runs only when Billing City has changed.
3. Use Update Records to update Contacts whose AccountId equals the triggering Account's Id.
4. Set the Contact field to the Account's new Billing City.
5. Let Salesforce handle the collection update rather than performing a separate DML operation for every Contact.

This is significantly better than putting an individual Update Records inside a loop, because Flow can perform the update as a collection and reduce unnecessary database operations.

Yes, the Flow can be triggered again when it updates the same Opportunity. Salesforce does not automatically prevent recursion in every case. 

To avoid unnecessary re-execution: 

•  Use “Only when a record is updated to meet the condition requirements” when possible. 
•  Add a Decision checking whether the target field actually needs to change. 
•  Use a Boolean/flag field such as Processed__c to prevent repeat processing. 
•  Prefer Before-Save Flow for same-record field updates when no related records/actions are required. 

Design the Flow so the update makes the record fail the trigger/decision condition on the next execution, preventing an unnecessary loop. 

Hey Misty, 

Your read is accurate: per Salesforce's own docs, Related Record Matching is an org-wide, all-or-nothing setting, when it's on, ECI runs its own algorithm (participant email/domain matching against Contact, Lead, Account) and populates the Related Record field automatically. If you want to run your own Flow-based matching logic instead (your name-against-Contact/Lead + subject line idea), you have to turn Related Record Matching OFF entirely, then a Flow becomes the only thing setting that field. You can't layer a supplemental Flow on top of the native matching to "catch the extra 10-20%", it's one or the other, not additive. 

Given that, your options really are: 

1. Turn off native matching, build your own Flow to replicate ECI's built-in logic PLUS your extra fallback rules (name-against-Contact/Lead, subject line parsing). This means you inherit responsibility for the baseline matching ECI already does well, not just the edge cases, that's a bigger lift than it initially sounds. 

2. Keep native matching on, and instead build a separate Flow/batch job that runs afterward on unmatched records only, checking if Related Record is null, then applying your own supplemental logic to update it. This avoids fighting the native system since you're only touching records ECI already gave up on, not replacing its matching entirely. 

3. Turn on Einstein Activity Capture integration alongside ECI, per Salesforce's own guidance, this specifically enhances guest participant matching quality, which sounds directly relevant to your "joining from a car/conference room" problem, worth testing before building custom logic at all. 

On

or similar tools: since ECI's matching is a Salesforce-side process, not tied to which video/transcription vendor recorded the call, a third-party transcription add-on wouldn't conflict with ECI's matching logic, but it also wouldn't replace or feed into it automatically. It solves a different problem (better transcript quality) than record-matching itself. 

Given the scale you're describing, option 2 (supplement only nulls, don't disable native matching) is usually the least disruptive path, worth prototyping that before considering a full matching rebuild. 

Reference: