#Service Cloud토론 중인 항목 64개

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.

Hi everyone,

I'm finding this a bit confusing and was hoping someone here could help clarify.

According to this Salesforce article, if Open CTI users are intended to use a particular Presence Status, we should remove the VoiceCall object

 from the supported Service Channels associated with that Presence Status. 

In our environment, we're using Five9 as our third-party telephony provider.

However, when I try to remove the VoiceCall object from the Presence Status configuration, Salesforce doesn't allow me to leave the object  field blank. It requires me to select another Object, meaning I cannot set it to null or simply remove the association.

Am I misunderstanding Salesforce's instructions, or is there another way to configure this correctly for Open CTI users?

Has anyone using Five9 or another third-party CTI provider encountered this issue? I'd appreciate any guidance on how you've handled this configuration. 

Thank you,  

Mit  

#Telephony Integration  #Service Cloud  #Omni Channel

Hi Trailblazer Community, 

I’m currently preparing to migrate existing WhatsApp numbers into Salesforce Service Cloud using Digital Engagement, with incoming conversations routed to agents through Omni-Channel. We already have Facebook Messenger channels running through Digital Engagement and Omni-Channel, so I’d really appreciate hearing from anyone who has completed a similar WhatsApp migration, particularly when migrating existing production numbers from another provider. 

There are a few areas where I’d be interested in hearing about your experience: 

1. WhatsApp vs. Facebook Messenger setup

Can we expect to reuse most of our existing Messenger setup and routing approach — for example queues, routing configurations, Omni-Channel, Messaging Components, automated messages, opt-out/STOP handling, and business-hours logic? Or are there important WhatsApp-specific differences or limitations we should plan for? 

In particular, which parts of an existing Messenger implementation can typically be reused, and which parts normally require separate configuration for WhatsApp? 

2. Two-step verification on the WhatsApp Business Account / phone number

Salesforce documentation indicates that two-step verification needs to be disabled as part of the connection/migration process. 

What I’m less clear on is when it can safely be enabled again.

Can two-step verification be re-enabled immediately after the number has been successfully connected to Salesforce, or does it need to remain disabled until the WhatsApp channel has been activated and the migration/cutover is fully complete? 

Related to this, when the number is initially connected to Salesforce, does the WhatsApp channel start in an inactive state, allowing us to complete the Salesforce configuration before activating it? 

3. Access to the actual WhatsApp phone number during setup

Do we need to have someone available during the migration who has access to the actual phone number? For example, is a verification code sent by SMS or phone call during the Salesforce/Meta setup that needs to be entered manually? If so, at what stage does this happen? 

I’m particularly interested in understanding which people and access we need to have available during the production cutover so we can plan this in advance. 

4. Migration from the existing provider and downtime

The numbers are currently handled through another platform (Falcon/Brandwatch). 

One of the main things I’m trying to clarify is the relationship between connecting/configuring the number in Salesforce and the actual production cutover. 

When the number is initially connected to Salesforce, does it remain active and operational through the existing provider while the Salesforce WhatsApp channel is inactive? In other words, can we connect the number, complete the Salesforce configuration, routing, etc., and then activate/cut over at a later planned time? 

If so, what exact action triggers the number to stop working through the existing provider and start working through Salesforce? 

For example, does the cutover happen:

• When the number is initially connected to Salesforce?
• When the WhatsApp channel is activated in Salesforce?
• During a separate Meta/WhatsApp migration step?
• At another point in the process?

Understanding this distinction is particularly important for our cutover planning, as we’d ideally like to complete as much of the Salesforce configuration as possible while the number is still operational through the existing provider. 

I’d also be interested in any experience with downtime during the migration. Was there a period where the number was unavailable on either platform, and if so, approximately how long did the cutover take? 

5. Rollback considerations

For anyone who has done this in production, how did you approach rollback planning? 

If an issue is discovered after the number has been migrated and activated in Salesforce, is there a practical way to move the number back to the previous provider? Or should the migration effectively be treated as a one-way cutover, where rolling back would require performing another provider migration? 

Any experiences, lessons learned, documentation, or recommendations around planning the production cutover would be greatly appreciated — particularly anything that caught you by surprise during the migration. 

Thanks in advance! 

#Service Cloud  #Digital Engagement  #Whatsapp  #Messaging  #Messaging Channels  #Omni Channel