#Service Cloud113 diskutieren mit

Has anyone else noticed a sudden change in how Salesforce handles inbound .eml attachments via Email-to-Case recently?

The Setup: We have government customers who, for security compliance, regularly send case details, reproduction steps, and screenshots packaged inside .eml file attachments.

The Issue:

• Previously: Salesforce successfully ingested the file wrapper and stored it as a clean .eml file under the Files/Attachments related list. Agents could download it, and it would open seamlessly in Microsoft Outlook with all formatting intact.
• Now: Salesforce appears to be actively stripping or parsing the .eml extension upon ingestion. The file is being split into separate, unformatted .txt and .html files (or the extension is stripped entirely upon download), forcing agents to manually re-append .eml to the filename just to read it.

Troubleshooting Done: We checked File Type Security settings (/lightning/setup/FileTypeSetting/home), but .eml isn't a standard option available to modify download behavior. I also pulled up a historical case from right before the platform behavior changed, and verified that the exact same

type of inbound email previously imported perfectly as a single .eml file. 

This feels like a recent backend regression or a quiet change to the platform's file-scanning/MIME-type engine. Related to Summer 26 release. (Maybe this: https://help.salesforce.com/s/articleView?id=release-notes.rn_experiences_files_malware_scanning.htm&release=262&type=5

) ? 

I’ve reopened a case with Salesforce Support. Is anyone else seeing this behavior in their orgs, or has anyone found a workaround that doesn't involve forcing agents to manually rename extensions all day? 

Appreciate any insights!

Hello Trailblazer Community, 

I am a Salesforce developer and long-time security operations professional looking to build a custom portfolio/proof-of-concept project. My goal is to configure a Salesforce Developer Org to mimic the core behavior, data models, and logic of enterprise security workforce tools—specifically mirroring the predictive dispatch and incident tracking functionality of Allied Universal’s HELIAUS platform.

I am looking for architectural advice on standard object mapping, custom object schemas, and automation design to achieve this single goal: 

Core Objective: Predictive Guard Dispatch & Incident Triage

• The Goal: Field guards use mobile devices to log incidents/checkpoints, and an engine tracks trends to suggest proactive patrol routes and risk mitigations.
• My Salesforce Strategy: I am leveraging Service Cloud. I plan to map distinct Client Locations/High-Rises to the standard Account object and physical sub-zones/buildings to the Location object. I will use Cases to represent security incidents (e.g., trespass, maintenance hazards, medical emergencies) with custom status picklists for Triage Levels.
• The Architecture Dilemma: I want the system to dynamically suggest "Proactive Guard Patrol Tasks" based on historic Case density at a specific Location. For example, if a high-rise has a spike in trespass Cases on the loading dock between 18:00 and 22:00, the system should automatically generate a high-priority Patrol Task for the guard on duty during those hours.

My Questions for the Community:

1. What is the most scalable way to architect this predictive routing/task element? Should I use Flow Builder to trigger these proactive Tasks using a scheduled flow that evaluates historic Case density, or is this a viable use-case for Einstein Prediction Builder / Agentforce in a free developer sandbox environment?
2. How should I structure a junction object between Locations and Cases if a single incident overlaps multiple physical zones, ensuring the data remains clean for analytics reporting?

I would love to hear your thoughts on custom data models, pitfalls with predictive logic in Flow, or integration ideas for feeding mock security data into Salesforce.

Thank you in advance for your insights! 

Future Roadmap Goals (For Future Sprints):

• Future Goal 2: High-Volume Security Roster Scheduling, Guard Card certification tracking, and Overtime (OT) mitigation logic using custom objects or Field Service Cloud.
• Future Goal 3: Conversational AI Automated Screening (Cloning the "Lisa" recruitment bot) using Einstein Bots or Agentforce to feed the applicant pipeline.

#Service Cloud  #FlowBuilder  #Einstein Prediction Builder  #Agentforce  #Salesforce Developer  #Salesforce Field Service

We created a new email-to-case configuration and new organization-wide email address in a sandbox. The configuration was done by our Release Management user (which doesn't have the System Administrator profile).    End users received their respective verification emails but were unable to complete the verification process. They clicked on the link in the email which opened up a browser window with the Verify Email Address button. After clicking on the Verify Email Address button, the browser screen appeared to be refreshing or reloading for several minutes and never displayed a confirmation message. We confirmed the verifications were still pending in setup.    We worked with multiple users and retriggered the verifications multiple times (ensuring that links in the email were only clicked on once) but the only way we could get a successful verification was if the person retriggering the verification and clicking on the link in the email had the System Administrator profile.    I submitted a Salesforce Support case to inquire if there was a process change. The resolution indicated that there might be an issue with a Summer '26 patch and timing of user verification of email addresses on their own user record in our sandboxes. We did some light experimentation in other sandboxes but still couldn't get the verifications completed without a System Administrator. Given the resolution we had been provided, it seemed that we shouldn't encounter the issue in production so we moved forward and created the email-to-case and organization-wide email address in production.    Unfortunately, we had the same issue in production so someone with the System Administrator profile both retriggered the verification emails and clicked on the verification link in those emails.   

Has anyone else encountered this behavior?    TL;DR, someone with the System Administrator profile had to trigger the verification email AND click on the verification link in that email in order to successfully verify new email-to-case and organization-wide email addresses.