Skip to main content

#Messaging Channels2 diskutieren mit

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

1 Antwort
  1. 27. Sept., 13:01

    Hi Christoffer, 

    A lot of the existing Digital Engagement/Omni-Channel architecture can be reused, such as queues, routing configurations, Omni-Channel flows, and business-hours handling. However, WhatsApp has some channel-specific setup and Meta/WhatsApp requirements, so I’d validate each component rather than assuming the Messenger configuration can be copied directly.  

     

    For the migration itself, I’d plan for someone to have access to the WhatsApp number and the required Meta Business Manager/WABA permissions during the setup, since verification and migration steps can require access to the number.  

     

    For the cutover, I’d also treat the connection/migration and the actual channel activation as separate steps in your runbook and test the complete flow in a non-production environment first. The exact behavior can depend on the WhatsApp/Meta setup and the existing provider.  

     

    Since you have several production-cutover questions around 2-step verification, activation timing, downtime, and rollback, I’d recommend confirming those specific points with Salesforce/Meta for your exact migration scenario before scheduling the cutover. If you can share the Salesforce WhatsApp setup/documentation you’re following, the community can also comment on the specific steps. 

0/9000

In legacy chat, you could use a merge field to greet the customer, I can not find anywhere in MIAW to do the same. I know you can create auto-messages in service cloud messaging channels but I can't see how you reference the customers name they entered in the pre-chat form.

 

I just want to say "Hello [Customer Name], how can I help you today?"

 

I'm just trying to create feature partity with legacy chat and finding it diffcult to.

 

Thanks @Sophie Barton @Maria Hamlett

7 Antworten
  1. 6. Nov. 2025, 23:29

    I also want to merge firstname in the system message something like in the screenshot. Logged-in user's firstname is available in MessagingSession record. @Emily Page

    Is there any way we can achieve this? 

    I also want to merge firstname in the system message something like in the screenshot. Logged-in user's firstname is available in MessagingSession record. Is there any way we can achieve this?

     

     

0/9000

I was configuring messaging for web for my digital experience site in scratch org with routing type (queue/flow). I setup everything as per salesforce help page. 

After publishing the experience site, it won't show component on page.

In console, it shows this error,  "Unable to load Embedded Messaging configuration". 

I have added CORS, Trusted sites. I retested the setup. I have tried to show messaging component on VF page too but component is not visible.

am I missing something? please help.

Thanks in advanced.

#Messaging Channels #Service Cloud

9 Antworten
  1. 10. Juni 2025, 08:03

    Embedded Service Deployment Settings

    I redeploy this settings, and that work for me  

     

0/9000

Hello FSL Trailblazers,

 

We just published a new app on AppExchange to help you setting up Einstein Bot, Messaging and FSL to offer appointment booking via SMS to your customers!

 

You can now find Rider on the AppExchange: https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMdIiUAL

Using nearly only configuration, this package will help you to understand better how to use Einstein Bot, Messaging & FSL to offer Appointment Booking via SMS amongst other things. You just need to install it, tweak a few small items and should be good to go if you have the right license of course.

 

Let us know what you think!

1 Kommentar
  1. 21. Juni 2022, 06:15

    Hi @Gary Brandeleer and @* Salesforce Field Service *! 

     

    In the documentation for Rider installation, it specifies that we need to utilise Work Types to "Ensure these work types auto-generate Service Appointments."  (Link to documentation here: https://quip.com/UV0NAhYfu6aw)

     

    In the org in which we would like to explore Rider Bot, we are not creating Service Appointments through the "Auto-Create Service Appointment" checkbox, but instead using a Flow to create our Service Appointments and assign necessary values. 

     

    Would we still be able to use Rider in this scenario? Or do we need to configure our Service Appointments creation to be done via Work Types?

     

    Many thanks in advance for your help! 

    #Einstein Bots #SMS #Messaging Channels #Salesforce Field Service

0/9000

Hi Team ,

Messaging Session issue:

 

I created a messaging session from case trigger. when i send a message to end user mobile it is not being delivered to them and it is not getting saved in conversation entry.

could you also please let me know how do you generate a proper session key?

Please help!

1 Kommentar
0/9000