We implemented Service Cloud back in October and had Omni-Channel built on AWS for our implementation to receive and call out from within our Org. We also have Microsoft Teams (Desktop and Web version). Since we went live, we have had issues with our headsets staying connected and visible within Omni-Channel's settings. The Input and Output options will not show up for 20, 30, 60 minutes and it at times takes multiple clearings of the browser cache, closing out the browser completely, and reboots and then it will randomly come back. There is no particular amount of time that passes before it does show up. It has caused a lot of our agents major headaches. We use Jabra wireless and/or bluetooth headsets. Some of the headsets have a docking station that connects to the computer, some have a USB dongle, and some are straight bluetooth. Same issue, no matter what. We have tried implementing another brand, Yealink into the mix, and same results. Our front desk users will boot up their laptops, open their browsers and wait for what seems like forever, before they can go online. Has anyone else had this same issue, and what have you done? Another question is - if you use Omni-Channel and Microsoft Teams for the Web - what issues have you seen? We use the web version and the Desktop version, and if you put someone on hold on the desktop version or go on hold in a meeting to answer to accept a call on Omni-Channel, it kicks you off the Teams call/meeting. We are going live with our next phase of deployment to users in 2 months and I would like to see if we can get ahead of this issue we are having. @* Service Cloud *
#Service Cloud109 utenti parlano di questo argomento
- AttivitĆ recente
- Data di creazione
- Consigliati
- Tutte le domande
- Domande con risposte accettate
- Domande senza risposta
- Domande senza risposta accettata
Hi all,
I've built an Agentforce Service Agent connected to WhatsApp via an Enhanced Messaging channel, and I'm stuck on a specific outbound failure after getting past several other setup hurdles. Hoping someone's hit this exact combination before.
Setup:
- Enhanced WhatsApp channel, Meta Business Account connected, number verified
- Routing Type: Omni Channel Flow -> Agentforce
- Fallback Queue configured with a Routing Configuration attached
What's working:
- Inbound messages from WhatsApp are reaching Salesforce fine ā I can see Messaging Sessions being created (MS-00000001, etc.) with correct timestamps and the customer's message logged
- Delivery checkmarks show on WhatsApp (message reached Meta)
What's broken:
Every attempt to send anything back to the customer ā including the standard opt-in prompt ā fails with:
"Can't send messages from this channel. Ask your admin to check the channel settings and contact Salesforce Customer Support."
ā logged as Automated Process
So it looks like an asymmetric failure: inbound works, outbound doesn't. I've already tried:
- Refresh Connection on the channel (no change)
- Re-registering the messaging session
- Confirming the channel shows as Active in Messaging Settings
- Double-checked Automated Response components are correctly linked (not free-typed text)
Has anyone run into this specific "Can't send messages from this channel" error on an Enhanced WhatsApp channel where inbound works but outbound doesn't? Trying to figure out if this is a Meta-side WABA/token issue or a Salesforce-side channel misconfiguration before I open a formal support case.
Appreciate any pointers ā happy to share more config details if useful.
#Service Cloud
In the past, I faced similar issue due to Consent Status.
https://www.infallibletechie.com/2022/03/cant-send-messages-to-this-recipient.htmlPlease raise a Case with Salesforce Support.
We are migrating our customer service operations from Zendesk to Salesforce Service Cloud, but we are facing significant challenges with data mappingāand especially with extracting case attachments for upload into Service Cloud. Could anyone who has gone through this process offer some assistance?
@Abhishek R I need to figure out the best approach for extracting the files and loading them into Salesforce! Thatās the part Iām struggling with the most.
Hi everyone,
I have a question regarding the upcoming MFA enforcement for all employee users
.
Let's consider this scenario:
If organization has five administrators who all use the same System Administrator username and password (shared login). The email address associated with that Salesforce user belongs to me.
When Salesforce prompts us to register a Passkey
, I complete the registration using my device because the email is mine. After that, when another administrator tries to log in using the same shared credentials, Salesforce requires the registered passkey, which only I have. As a result, the other admins are unable to log in.
How should organizations handle this situation?
- Is sharing one System Administrator account no longer supported with passkeys?
- Does Salesforce expect every administrator to have their own individual user account?
- If a shared admin account must be used (for legacy reasons), what is the recommended approach to satisfy the new MFA/passkey requirement?
I'd appreciate any guidance or best practices from the community. Thanks!
#Salesforce Developer #Salesforce Admin #Trailhead #Salesforce #Service Cloud
@Sourabh Dondekar, shared admin logins are not the right approach anymore, especially with MFA/passkeys. Each admin should have their own named Salesforce user account, with their own MFA method or passkey. This is also important for audit history, setup changes, login tracking, and accountability.
A passkey is tied to the user/device that registers it, so if five people share one admin login, the others can get blocked when Salesforce asks for that passkey.
Kindly check this for reference: https://help.salesforce.com/s/articleView?id=xcloud.mfa_supported_verification_methods_bia.htm&type=5
I have inlucded the activity tab on the Case object. But the email action is visible even after adding the email action on the page layout. I have attached the screenshot for reference.
I don't face this issue on the Account object.
Help me to fix this issue.
@* Sales Cloud - Best Practices * @* Service Cloud * @* Sales Cloud - Best Practices *
#Service Cloud
We need to verify how Accounts and Cases are mapped for inbound calls, transfer calls, and outbound calls in the Voice Call record. When we click a phone number from an Account, an outbound call is created and the RelatedRecordId field is updated with the Account ID. If we initiate a call from a Case or Lead, the respective record ID is automatically populated in the RelatedRecordId field on the Voice Call. Could you confirm whether this is standard Salesforce behavior? If so, please share the relevant documentation. @* Service Cloud *
Yes, this is generally standard behavior.
For outbound click-to-dial calls, Salesforce uses the record where the call was started as the call context, and its ID can be stored in VoiceCall.RelatedRecordId.
For inbound calls, Salesforce first tries to match the callerās phone number to a Contact. Account matching can then occur through the matched Contact. A Case is not always linked automatically unless it is provided through the call flow, telephony integration, or manually linked by the agent.
For transferred calls, Salesforce can create a separate Voice Call record for each call leg. The records are connected through the previous and next call relationships, but custom flow or telephony logic may be required to copy the same RelatedRecordId to each transferred call.
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!
Hi Martha,
we have noticed the same sudden change and issues for our agents.
They used to download and open (Outlook) the original .eml file attached to the email/case related lists ā and expect it to be there.
Moreover, the "original .eml file itself" ā as mentioned in
https://help.salesforce.com/s/articleView?id=005101786&type=1 ā will not be present, but another file without any extension.Have you heard anything from Salesforce Support?
Thanks,
Martin
We are deploying Enhanced Bots (Einstein Bots) on our company website using Embedded Messaging. We've enabled "Conversation Transcripts on Data Cloud" to analyze bot conversation data via reports. **Goal:** We want to filter out internal employee conversations from analytics/reports so we can focus on actual customer interactions. **Challenge:** Since Embedded Messaging is accessed via a public website (no login required), there's no built-in way to identify whether a conversation was initiated by an internal employee or an external customer. The ConversationEntry data in Data Cloud doesn't include any user identity or IP address information. **What we've considered so far:** 1. **Hidden Pre-Chat fields** ā Using the Messaging Web API to pass a hidden field (e.g., a flag set by server-side IP detection) before the conversation starts. This seems viable but requires custom web implementation. 2. **Adding a bot question** ("Are you an employee?") ā Rejected because it adds friction and may reduce utilization rates. 3. **Separate deployment per audience** ā Deploying different Embedded Service configurations for internal vs external pages, but this adds operational complexity. **Questions:** - Is there a recommended or built-in way to tag/identify user type (internal vs external) in Enhanced Messaging conversations? - Has anyone successfully used Hidden Pre-Chat fields with Enhanced Bots to pass custom metadata that appears in Data Cloud transcript data? - Are there other approaches we haven't considered? **Environment:** - Salesforce Enterprise Edition - Enhanced Messaging channel with Enhanced Bots - Data Cloud enabled for conversation transcript analysis - Embedded Messaging for Web (MIAW)
If the response feels appropriate and helpful, could you please mark it as helpful / Mark as solution, so as to help others reach to the answer quickly @Takuya Kusano. Thanks in advance.
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:
- 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?
- 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
Excellent use case and a strong example of extending Salesforce beyond traditional CRM workflows.
From an architectural perspective, I would recommend treating predictive patrol generation as a separate domain rather than creating Tasks directly from incident records. A dedicated custom object such as Patrol Recommendation or Risk Assessment provides a cleaner separation between operational incidents and system-generated intelligence. This approach improves auditability, reporting, and future scalability as the recommendation engine becomes more sophisticated.
For the data model, your proposed Account ā Location hierarchy is sound. To support incidents affecting multiple physical zones, I would introduce a junction object between Cases and Zones/Locations. This avoids data duplication, preserves referential integrity, and enables more accurate analytics when evaluating incident concentration across overlapping areas.
Regarding predictive logic, a layered architecture would likely be most scalable:
ā¢ Case creation and enrichment via Record-Triggered Flows
ā¢ Scheduled aggregation of incident metrics into summary objects (by Zone, Incident Type, Time Window, and Severity)
ā¢ Recommendation generation based on configurable risk thresholds
ā¢ Patrol assignment and dispatch workflows consuming those recommendations
I would caution against calculating historical density directly against large Case datasets within Flow as volume grows. Pre-aggregated metrics will perform significantly better and align more closely with enterprise-scale security operations platforms.
For a portfolio project, Flow Builder is more than capable of demonstrating the core concept. However, Agentforce could add significant value by providing contextual reasoning around recommendationsāfor example, explaining why a patrol was suggested, identifying recurring incident patterns, or proposing mitigation strategies based on historical trends. This would make the solution feel closer to a modern intelligence-driven operations platform rather than a rules-based dispatch system.
Looking ahead, Field Service could also become a natural extension of this architecture. Guards can be modeled as service resources, patrols as work orders or service appointments, and optimization logic can evolve toward workforce scheduling, route optimization, certification tracking, and overtime management.
Overall, the architecture direction is solid. The key design principle I would emphasize is separating raw operational events (Cases) from analytical intelligence (risk scoring, recommendations, patrol generation). That separation will make the platform significantly easier to scale, maintain, and evolve as additional predictive and AI capabilities are introduced.
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.
Thanks for sharing this experience. We have observed similar behavior in sandbox environments where email address verification appears to remain pending unless the process is completed by a user with System Administrator permissions. Given the information from Salesforce Support, this may be related to a platform issue rather than a configuration problem. It would be helpful to know if others have seen the same behavior in Summer '26 sandboxes or if it has been resolved in production environments.