#Record-Triggered13 debatiendo

Hi @Rakesh Goud You can use an After-Save Record-Triggered Flow to automatically update related records when an Account's Industry changes.

Steps:

1. Go to Setup → Flows → New Flow → Record-Triggered Flow.
2. Select Account as the object.
3. Trigger the Flow when a record is updated.
4. Select After Save because we need to update related records.
5. Add a Decision element to check whether the Industry has changed.
6. Use Update Records to update the related records, such as Contacts, based on the Account Id.
7. Save, debug, and activate the Flow.

How to prevent recursion and unnecessary updates:

• Use ISCHANGED(Industry) to run the Flow only when Industry changes.
• Set the entry criteria to run only when the record meets the required conditions.
• Update only related records that actually need changes.
• Avoid updating the same Account again unless required.
• Check whether any other Flows or Apex Triggers could update the Account again.
• Use one Update Records element for matching records instead of updating records individually in a loop.

Real-Time Example:

If an Account's Industry changes from Banking to Healthcare, the Flow can automatically update a custom Industry field on all related Contacts.

Useful Salesforce Documentation:

• Record-Triggered Flows – Trailhead
• Flow Builder – Salesforce Help
• Flow Best Practices – Salesforce Architects

My suggestion: Use an After-Save Flow with change detection and filtered updates. This helps avoid unnecessary execution and reduces the risk of recursion.

Hope this helps!

Hi @SAITEJA B Good question! Record-Triggered Flows are a great way to automate business processes in Salesforce without writing Apex code.

1. Recommended Flow Design

Scenario: When an Opportunity moves to Closed Won, update the record, send an email, and create a follow-up Task.

1. Create Flow: Setup → Flows → New Flow → Record-Triggered Flow.
2. Select Object: Opportunity.
3. Entry Condition: Stage = Closed Won.
4. Trigger: When a record is created or updated.
5. Run Condition: Only when the record meets the entry conditions for the first time.
6. Update Record: Update required Opportunity fields.
7. Send Email: Use the Send Email action to notify the Opportunity Owner.
8. Create Task: Create a follow-up Task assigned to the Opportunity Owner.

2. Important Best Practices

• Use an After-Save Flow for creating Tasks and sending emails.
• Use a Before-Save Flow when only updating fields on the triggering record.
• Avoid unnecessary Get Records and Update Records inside loops.
• Prevent repeated execution using entry conditions.
• Add fault paths and test using Flow Debugger.

3. Official Salesforce Resources

• Record-Triggered Flows
• Flow Builder Basics
• Flow Builder Documentation

Build this automation in a Developer Org and test what happens when an Opportunity changes from Negotiation to Closed Won.

Key Point:

Use Record-Triggered Flows for business automation without Apex, but always focus on performance, error handling, and avoiding duplicate actions. 

Hope this helps! Venkat Yadav | SFDCINDIA

Hi @Sai Kumar Good question! The best way to learn Salesforce Flows is to practice real-world business scenarios.

1. Practical Flow Scenarios

1. Record-Triggered Flow: Create a follow-up Task when an Opportunity is Closed Won.
2. Screen Flow: Build a customer registration or case creation form.
3. Scheduled-Triggered Flow: Check overdue Cases daily and notify owners.
4. Scheduled Paths: Send a reminder 3 days after a Lead is created.
5. Fault Paths: Handle Flow errors and log failure details.

2. Important Best Practices

• Use entry conditions to avoid unnecessary execution.
• Use before-save Flows for updating fields on the triggering record.
• Avoid unnecessary Get Records and Update Records inside loops.
• Prevent recursion by checking field changes.
• Test using Flow Debugger and different scenarios.

3. Official Salesforce Resources

• Flow Basics
• Record-Triggered Flows
• Screen Flows
• Flow Builder Documentation

Build one complete Lead Management project using different Flow types and error handling.

Key Point:

Don't just learn how to create Flows. Understand when to use each Flow type and how to troubleshoot issues. 

Hope this helps! Venkat Yadav | SFDCINDIA

Hi @Vinjamuri Teja The choice between Before-Save and After-Save Flow depends on the business requirement.

1. Before-Save Flow

• Use it to update fields on the same record.
• Runs before the record is saved.
• Faster and better for performance.
• Example: Automatically set Opportunity Priority based on Amount.

2. After-Save Flow

• Use it to create or update related records.
• Runs after the record is saved.
• Supports actions like sending emails and creating Tasks.
• Example: When an Opportunity becomes Closed Won, automatically create a follow-up Task.

Best Practice: Always prefer Before-Save Flow for same-record field updates and After-Save Flow for related-record updates or additional actions.

Hope this helps!

Hi @Abhiram Sailada Both Apex Triggers and Record-Triggered Flows are used for automation in Salesforce, but choosing the right one depends on the business requirement.

When I prefer Record-Triggered Flow:

• Simple to medium-complexity automation.
• Field updates, validations, notifications, and related record creation.
• Easy maintenance without writing code.

When I prefer Apex Trigger:

• Complex business logic and calculations.
• Advanced processing across multiple objects.
• Better control over bulk processing, performance, and error handling.

Real-time example:

Imagine an e-commerce company processing thousands of orders. For each order, we need to check inventory, calculate discounts, update stock, and prevent overselling.

In this scenario, I would prefer an Apex Trigger with a handler class

because we need more control over complex logic, bulk operations, and record locking. 

My suggestion: Always consider Flow first. If the requirement becomes too complex or needs more technical control, go with Apex.

One important point: Flow also supports bulk processing, so don't choose Apex just because the data volume is high.

@venkateswarlu Allipudi

Check the below trigger :

trigger PreventCaseDeletion on Case (before delete) {
    // Set to store IDs of Cases being deleted to minimize the query scope
    Set<Id> caseIdsBeingDeleted = Trigger.oldMap.keySet();
    // Query to find Cases that are being deleted and are related to both an Account and a Contact
    List<Case> casesWithAccountAndContact = [
        SELECT Id
        FROM Case
        WHERE Id IN :caseIdsBeingDeleted
          AND AccountId != null
          AND ContactId != null
    ];
    // Set to store the IDs of Cases that meet the criteria for prevention
    Set<Id> preventDeletionCaseIds = new Set<Id>();
    for (Case c : casesWithAccountAndContact) {
        preventDeletionCaseIds.add(c.Id);
    }
    // Loop through the Cases in Trigger.old to find matches and prevent deletion
    for (Case c : Trigger.old) {
        if (preventDeletionCaseIds.contains(c.Id)) {
            // Prevent deletion by adding an error to the Case record
            c.addError('Cannot be deleted because it is related to both an Account and a Contact.');
        }
    }
}

@Priyanshu Gupta thanks for the help!  Ive tried many variations of this kind of validation rule ALL with syntax errors.  Im starting to think that my Site Name look up fields and Site Name formula fields are causing the issue.  Im trying to look at the formula field of current records to see if there are existing values.

Here are some example value names to help with another try!  

object name =  site support details

lookup field = Site Name

formula filed = SSD Site (this field populates what the user selects from the site name look up field)