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

Hi @Ariana Bayona,  

Why it’s intermittent: If your Org-Wide Email Address is a Gmail or Yahoo address, Gmail’s DMARC policy tells receiving servers to reject mail with an @gmail.com From address that doesn’t come from Google’s own mail servers. Mail from Salesforce can’t be DKIM-signed for a domain you don’t own, so it gets through at some receivers and is rejected at others. A verified org-wide address only proves you own the mailbox. It doesn’t authenticate the domain. sage

Options without buying a domain:

1. Use the substitute-address setting (best free fix). In Setup > Deliverability, enable “Use a substitute email address for unverified domains.” Salesforce then sends from a technical address in the form email@UniqueId.sfcustomeremail.com, using its own verified domain. Keep your real address as the Reply-To so replies still reach you. Check the exact setting name and location in your org. I haven’t confirmed where it sits in the current UI. salesforcebreak
2. Send From a domain you already have access to. If you can use an address on a work or school domain, ask whoever manages that domain’s DNS to set up a DKIM key (Setup > DKIM Keys) or add it as an Authorized Email Domain.
3. Buy a cheap domain. It’s roughly $10/year. Both DKIM keys and Authorized Email Domains require a domain you can add DNS records to, so there’s no free route to full authentication.

Check first: Open the failed messages in Email Logs and confirm which From address was used. Salesforce also now requires verified sending domains (from Spring ‘26, emails must come from a domain verified as belonging to your organization), so if your From is a free-mail address, this change could be part of why delivery became unreliable. If your From is not a free-mail address, tell me what it is and I’ll rework the diagnosis. salesforceben

Sources:

• Salesforce’s New Email Domain Verification Explained (Salesforce Ben)
• The Salesforce DKIM Sandbox Problem, and How to Fix It
• Email authentication for outgoing emails (Sage People)

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Hi @Lazizhon Ahmedov, 

This appears to be a known behavior in Salesforce's standard approval email notifications. The official Salesforce documentation mentions: 

“Emails sent after a reassignment may include the extra word ‘null’ in the body. You can ignore this text.” 

Reference:  Salesforce Help – Approval Email Notification Behavior

You can also refer to this LinkedIn post for additional context. 

Hopefully, Salesforce will address this behavior in a future release to prevent the unwanted null text from appearing in approval emails and provide a cleaner user experience. 

Hope this helps!

@Nizar Am  From the canvas, the likely culprit is the Get Delegations element. I can't see what's inside each element, so the rest is inference until I see them. 

1. Get Delegations looks redundant and probably breaks things 

A schedule-triggered flow already runs once per record of Absence Delegation, and each run has that record as {!$Record}. A Get Records element right after the Start element means one of two things: 

• It returns one record (the first match). Then the Decision and updates run against that record, not the one the interview is processing, so most records are skipped or the wrong one is used.
• It returns a collection. Then the Decision can't compare a date on it, and anything using it is unreliable.

Debug is more forgiving because you pick a single record, so it can look fine there and fail on the scheduled run. 

, use {!$Record.Start_Date__c} = {!$Flow.CurrentDate} for "Start Date is Today" and {!$Record.End_Date__c} = {!$Flow.CurrentDate} for "End Date is Today". $Flow.CurrentDate works inside a Decision, just not in the Start element's entry conditions. 

Both Update Records elements should be on

, with a filter of Id = {!$Record.CreatedById} (or a dedicated Manager lookup, which is safer). 

• Add Delegate: set DelegatedApproverId = {!$Record.Delegate__c}.
• Remove Delegate: set DelegatedApproverId to null. Use "Set field values" and leave the value blank, or use a null/empty text variable.
• Don't use "Use the IDs stored in a record variable" on a User from a Get. If the User comes from $User, the scheduled run lands on the Automated Process user, which matches what you saw.

• Start time: it's set to 11:15 today, which has already passed in your time zone (it's about 17:00 for you). Confirm in Setup → Scheduled Jobs that the job exists and shows a next run for tomorrow. Also check the flow is Active, since a saved but inactive flow won't run.
• Failures: Setup → Paused and Failed Flow Interviews and the flow error emails will show what the last scheduled run did.
• No fault paths: the two updates have none. Add them, since a failed User update would otherwise be silent.
• Entry conditions: the Start element has none, so every Absence Delegation record is processed daily. That's fine at low volume. If it grows, add formula fields (Starts_Today__c, Ends_Today__c) and filter on them in the Start element.

@Roopa Sharma, This is a good area to learn early. Many orgs end up with documents in both systems, and the friction shows up exactly where you listed. Here is how each one tends to play out once a setup is live.  

1. Where the documents live - 
   • SharePoint as the home, with Salesforce records pointing to it. The usual choice when the company already runs on Microsoft 365.
   • Salesforce Files, when volumes are small and only CRM users need the documents. The Files related list is flat, with no folders per record.
2. Ways to connect the two
   • Files Connect (native): lets users browse, search and attach SharePoint files from Salesforce, but it does not create a folder per record.
   • Power Automate: a good fit if your team already builds on the Microsoft side. The trade-off is that the logic lives outside Salesforce, on a premium connector. 
   • AppExchange apps: compare them on four things. Does Flow create a folder when a record is created? Do uploads from the record go straight to SharePoint? Do SharePoint's own permissions still apply? Can you trial it in a sandbox first? 
3. Your questions, in practice - 
   • Folder structure: mirror your data model (Account, then Opportunities, then each opportunity), with the same subfolders on every record. Add the record ID to folder names so a rename never breaks a link. 
   • Metadata: tag files with SharePoint columns such as document type, status and record ID, instead of relying on folder names.
   •  Version control: let SharePoint's version history handle it, and avoid saving copies back into Salesforce. 
   • Security: SharePoint decides who can open a file. Salesforce sharing does not carry over to SharePoint on its own, so plan who updates access when an account changes owner.
   • User experience: users should reach a record's folder from the record page, without searching SharePoint.

If you go the AppExchange route, CloudFiles is one app that works this way with SharePoint. With its flow actions, each record gets a folder when it's created, and files are tagged as they arrive. Users open that folder from the record page, and SharePoint's permissions decide what each person can see. https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000Gh9uFUAR

Disclosure: I work at CloudFiles.

Hi @Durga Prasad Karnaty I would first check why the Flow is running on every Opportunity update.

A few things I would suggest:

1. Entry Conditions: Run the Flow only when required conditions are met.
2. Run Settings: Use "Only when a record is updated to meet the condition requirements" where applicable.
3. Check Field Changes: Compare $Record and $Record__Prior to identify changes.
4. Decision Element: Continue only when relevant fields have changed.
5. Avoid Unnecessary Updates: Update related records only when needed.

Best Practice: Filter records early and avoid unnecessary DML operations to improve Flow performance.

Hope this helps!

Hi @Abhiram Sailada You can achieve this easily using an After-Save Record-Triggered Flow.

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 When a record is updated and Only when the record is updated to meet the condition requirements.
5. Select After Save because we're creating a related Task.
6. Add a Create Records element to create a Task with:
   • Subject: Follow up with Customer
   • Status: Not Started
   • Related To: Opportunity ID ($Record.Id)
   • Assigned To: Opportunity Owner ($Record.OwnerId)

Finally, save, activate, and test the Flow.

Best Practice: Make sure the Flow creates the Task only when the Opportunity changes to Closed Won, to avoid duplicate Tasks.

Hope this helps!