#Flows48 人がディスカッション中

Hi @SAITEJA B Good question! Both Validation Rules and Flows are used in Salesforce, but they serve different purposes.

1. Key Differences

• Validation Rule: Prevents users from saving records when required conditions are not met.
• Flow: Automates business processes such as creating records, updating fields, sending notifications, and approvals.

2. Your Business Scenario

I would recommend using a Validation Rule because the requirement is to prevent an Opportunity from moving to Closed Won when mandatory fields are missing.

Example Formula:

AND(
  ISPICKVAL(StageName, "Closed Won"),
  OR(
    ISBLANK(Amount),
    ISBLANK(CloseDate),
    ISBLANK(TEXT(Competitor__c))
  )
)

Assuming Competitor__c is a picklist field.

3. When to Use Each?

1. Validation Rule: When you need to stop incorrect or incomplete data from being saved.
2. Flow: When you need to automate actions based on business conditions.

4. Official Salesforce Resources

• Validation Rules
• Flow Builder
• Record-Triggered Flows

Use a Validation Rule for this requirement. It's simpler, easier to maintain, and prevents incomplete Opportunity records from being closed.

Key Point: Validation Rules control data quality, while Flows automate business processes.

Hope this helps! Venkat Yadav |

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

The first thing to check is whether the Flow is querying or updating records inside a loop. That can quickly become a problem as record volumes grow. 

A few things that usually help: 

• Move Get Records and Update Records operations outside loops wherever possible.
• Use record collections to process multiple records together instead of updating them one at a time.
• Filter queries carefully and retrieve only the fields and records you need.
• If the logic involves complex processing or large data volumes, consider Apex or Batch Apex. Salesforce Flow isn’t always the best fit for every workload.

One other thing to consider: if a significant part of the Flow handles lead-to-account matching or lead assignment, you may be able to move that responsibility to a dedicated tool rather than maintaining all the logic in Flow. LeadAngel, for example, handles lead-to-account matching, deduplication, and lead routing alongside Salesforce. That won't fix inefficient Flow queries directly, but it may help simplify the routing and matching logic your team needs to maintain. 

I’d start by checking the Flow’s debug details and identifying which queries or updates are consuming the most resources before deciding whether to refactor it or move part of the processing to Apex. 

Hi @Pranay yerragunta I would recommend using an After-Save Record-Triggered Flow because we need to update a related Account record.

Implementation Steps:

1. Go to Setup → Flows → New Flow → Record-Triggered Flow.
2. Select Opportunity as the object.
3. Set the condition: Stage = Closed Won.
4. Choose Only when a record is updated to meet the condition requirements.
5. Select After Save (Actions and Related Records).
6. Add an Update Records element to update the related Account using $Record.AccountId.
7. Set Customer Status = Active Customer (or the required business value).
8. Save, Activate, and Test the Flow.

Why After-Save Flow?

• Before-Save Flow is mainly used to update fields on the triggering record.
• After-Save Flow supports updating related records.
• No Apex code is required for this straightforward requirement.

Best Practice: Test with multiple Opportunities and confirm the Account status updates correctly when an Opportunity changes to Closed Won.

Hi @Nich Weidman

When Salesforce sends a system email, it includes special header fields that identify the source organization and user. To identify the source, locate the following fields in the raw email headers:

• X-SFDC-LK — The Salesforce Organization ID (the 15- or 18-character org ID of the org that sent the email).
• X-SFDC-User — The Salesforce User ID of the user whose automation triggered the email.
• X-SFDC-EntityId — The record ID of the Salesforce entity (such as a workflow rule or report) that triggered the email.
• X-SFDC-Emailcategory — The category of the email (for example, workflow, report, or Chatter digest).
• X-SFDC-ORGTYPE — The type of org that sent the email. Note: this field only appears in emails sent from Free or Trial orgs. It does not appear for production, sandbox, or developer org emails.

Important:

Use the original .msg formatted email — not a forwarded copy. Forwarding an email overwrites the original headers, making it impossible to identify the source org. 

Find the User Id from

then go to set up and add a Debug trace for the user and then triggert the email. This will create a debug log for you to read and find the source. 

Check out these articles for more info:

1. Find the email headers for emails
2. How to Identify the Salesforce Organization That Sent a System Notification Email 
    

 Hii Lisa,

The 1–20 picklist values are not the issue. I would check the Flow’s loop or assignment

pattern first.

Make sure the picklist is assigned directly from Current Item from Loop to the new record variable, then add that record variable to the collection. Create the records after the loop, not inside it. Salesforce specifically recommends this pattern because the Current Item is reset on each iteration.

Also verify that the picklist values are "Active" and available for the target "Record Type"

 (and controlling value, if it’s dependent). 

Check this for references: 

 https://trailhead.salesforce.com/content/learn/modules/loops-in-flow-builder/build-a-loop

https://help.salesforce.com/s/articleView?id=platform.troubleshoot_picklist_values.htm&type=5