Skip to main content

#Digital Engagement10 discussing

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 answer
  1. Sep 27, 1:01 PM

    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

Hello! 

I'm looking for a workaround to be able to create a blank Messaging Session in an enhanced SMS channel. I know officially Salesforce does not provide a way to do so but for various business reasons, this is the solution that is needed. High level - based on a record trigger, we need to route a blank Messaging Session to a user via Omni Channel. The scenario covers existing customers with whom we had prior sms conversations as well as new customers with whom we've never communicated via sms. 

Has anyone figured out any ways around this limitation? 

 

#Service Cloud  #Digital Engagement  #Messaging Session

2 answers
  1. Sep 18, 6:44 AM

    Hi Svetlana,

     

    The short answer is that you cannot manually construct a valid ConversationId via standard Apex/Flow DML because in Messaging for In-App and Web (MIAW) and Enhanced Channels, the Conversation record is managed by Salesforce's backend Service Cloud Real-Time (SCRT2) fabric, not core Salesforce DML. Inserting a raw MessagingSession record without an underlying SCRT conversation context leaves it orphaned and unusable in Omni-Channel.

     

    However, depending on whether you want an automated greeting sent or a completely silent assignment, here are two tested patterns for this use case:

     

    Solution 1: Outbound Messaging Template (Recommended)

    Instead of generating an artificial "blank" session, trigger an outbound template message to initiate a real session.

     

    • How it works:
      1. Trigger an Auto-Response / Outbound Messaging Flow from your record trigger using an approved Messaging Template (e.g., "Hi [Name], an agent is reviewing your account and will connect shortly.").
      2. Because the message is sent via the standard messaging engine, Salesforce automatically creates the Conversation, provisions the ConversationId, and initiates an active MessagingSession.
      3. Route this newly initiated session through your Omni-Channel Flow to the agent queue.

     

    • Why it works: The agent receives an active session in their Omni-Channel widget, the conversation thread links seamlessly (for both new and existing customers), and the SCRT2 backbone recognizes the session.

     

    Solution 2: Agent-Initiated "Start Conversation" Quick Action

    If your business requirement strictly forbids sending an automated outbound text to the customer before the agent connects:

     

    • Use the Standard Enhanced Outbound Capability:
      • Route a custom Task, Case, or Work Order to the agent via Omni-Channel when the trigger condition is met.
      • Embed the "Send SMS" / "Start Conversation" Quick Action on the record page layout.
      • When the agent accepts the work item from Omni-Channel, they click the action to send their first custom message. Salesforce immediately opens the active MessagingSession console tab for the agent.

     

    Solution 3: SCRT2 / Connect REST API Outbound Trigger

    If you have developer resources and need complete headless automation:

     

    • Use the Connect REST API for Outbound Messaging (/connect/conversation/messages / Enhanced Channel API).

     

    • By calling the internal service endpoint rather than attempting an insert new MessagingSession(), the platform spins up the actual conversation payload and routes the resulting session to Omni-Channel as designed.
0/9000

I have been working on automating SMS delivery using the Digital Engagement Channel. Both the Channel and the Messaging Component are defined and active. I am using the "Send Conversation Message" action in a Flow to send the SMS.

The Flow executes successfully, and the ConvMessageSendReq returns a success report. I checked the Conversation and MessagingSession records, and they are populating correctly. I also verified that the running user has the required Messaging User license. Furthermore, I checked for a MessageDeliveryError, and no errors are being logged.

Despite all of this, the message is not being sent to the MessagingEndUser. The MessagingEndUser phone number is properly formatted in E.164 format with the country code. 

No ConversationEntry Record is being created.

Where am I going wrong? Did I miss a configuration step, or is there something else I need to check? 

 

#Digital Engagement  #Salesforce Developer

1 answer
  1. Sep 12, 3:58 AM

    @Prasanna Achar

     

    Yes, it does work differently in sandbox. Your Flow, licenses, and config are all fine, which is exactly why you get a success report with no errors. The message just never physically leaves the platform.  

    The actual SMS carrier provisioning, the phone number, and the live connection to the messaging provider behind Digital Engagement are tied to your production org.  Sandboxes get the config metadata copied over, so the Channel, number, and Messaging Component all look active and valid, but the live carrier binding doesn't exist in the sandbox.  

    Confirm with Salesforce whether SMS is actually provisioned for your specific sandbox. Usually it isn't by default, and real outbound SMS only sends from production. Some orgs can request a sandbox be provisioned for messaging testing, but it's not automatic and often not available. Thanks! 

0/9000

Hello Everyone, has anyone experienced "enable as partner" and "enable as partner user" actions not available on the page layout or record page for accounts & contacts? The digital experience was already enabled. We received gold partner licenses from our sister org. I was trying to setup users and found out how to do so but don't see the action that will kick it all off (on the account nor contact). I also have manage external users permission. I do see actions for community case, disable customer account and others. I've been googling but having hard time to come across a reason.

'Enable as Partner' Action Missing

 

Enable Partner User Record Page.png

 

 

#Digital Engagement

10 answers
  1. Divs Chauhan (kcloud) Forum Ambassador
    Sep 9, 8:26 AM

    Hi @Desiree Martinez

    , 

     

    Add Enable as Partner to the Account page layout and Enable Partner User to the Contact page layout under Salesforce Mobile and Lightning Experience Actions and

     

    the Contact must be associated with an Account.

     

    I hopo this help !!

0/9000

 For SMS, if we are using Digital Engagement, we use the Send Conversation Message Flow action to send the SMS.

For Email, Salesforce provides Apex classes such as Messaging.SingleEmailMessage. Does Salesforce provide an Apex equivalent of the Send Conversation Message action

for sending SMS through Digital Engagement? 

 

#Digital Engagement

1 answer
  1. Aug 11, 8:32 AM

    Hello @Prasanna Achar

     

    No, Salesforce does not provide a direct native Apex equivalent class (like Messaging.SingleEmailMessage) dedicated to sending Digital Engagement SMS messages. 

     

    Alternative Approaches to Trigger SMS from Apex: Call a Flow from Apex using Flow.Interview where the Flow utilizes the declarative Send Conversation Messages or Messaging Notification action.

0/9000
3 answers
  1. Aug 17, 6:09 PM

    I agree that branded short links are a better choice for customer-facing SMS. They look more trustworthy and can help avoid confusion around unknown shortened URLs. The time-zone point is also easy to overlook when setting up Business Hours.

0/9000

According to the documantation, the best practice of sending outbound messages is by creating a flows. is there a way to send bulk messages to a selected list of users (bulk)?

we do have thier consent of communicating with them via whatsapp so we can create them as opted in messaging users

6 answers
  1. Sep 1, 2022, 8:06 AM

    @Larry Hall @Kermit Del Rosario was surprised there is no out of the box functionality for bulk message sending. What I did > created a list view button on messaging user object, which launches screenflow, and allows the user to select a template, then sends outbound message.  hope that helps  

0/9000

We're trying to send out unique links to each contact as a text message from flow action - something like

"Hi John Doe, Please fill out Survey by clicking the below link

{Contact Specific Unique Link}"

I don't see an option to send the combination of text message & a contact specific unique link embedded in the text message. Did anyone try to achieve this? Please let me know as this is blocking our text message initiative to be able to send text + Unique links. Thanks!

9 answers
0/9000

Hi everyone,

We are looking for guidance on integrating Facebook Messenger and Instagram Direct with Salesforce Digital Engagement.

Context

WhatsApp is working correctly in Digital Engagement, but Messenger and Instagram are not connecting at all.

What is happening

  • We originally had a standard Messenger channel, which we deactivated.
  • Salesforce then created a new Enhanced Messaging channel, but the connection was never successful (it shows as authenticated and active, yet no messages ever reach Salesforce).
  • In Meta/Facebook, we cannot see any of the technical settings required for the API:
    • Advanced Messaging
    • Connected Apps
    • Primary Receiver / Handover Protocol
  • Salesforce Support suggested that the issue may come from the Facebook Page itself, possibly due to the migration to New Page Experience and loss of API permissions.
  • Instagram Direct also fails to connect, even though the Instagram business account is properly linked to the Page and the Business Manager.

Questions

  1. Has anyone experienced Facebook Pages losing Messenger API capabilities after moving to the New Page Experience?
  2. Did creating a new Facebook Page solve the issue in your case?
  3. Do you recommend using native Digital Engagement for Instagram, or a third-party connector / BYOC option?
  4. Any best practices for rebuilding the Messenger + Instagram integration from scratch?
  5. If possible, could you share any success stories or relatively “smooth” implementations of Meta (especially Instagram Direct) integrated with Salesforce?
    • What approach did you use? (native, partner app, custom integration)
    • Any key lessons learned?

Thanks in advance for any insights or recommendations!

@* Digital Engagement * 

3 answers
  1. Mar 21, 9:55 AM

    Yes, this issue can happen after switching to the New Page Experience, as Messenger API permissions may reset. Instead of creating a new Page, re-authorizing the Meta app and reconnecting integrations usually works. For managing Messenger and Instagram with Salesforce, many teams prefer third-party solutions like 360 SMS App for a smoother, centralized messaging integration. 

0/9000

Has anyone looked into or already setup SMS in Amazon Connect? It looks a bit arduous based on this documentation from AWS: https://docs.aws.amazon.com/connect/latest/adminguide/setup-sms-messaging.html.

 

Reason I'm asking, we have a use case where we'd want the phone numbers we claim in Amazon Connect that are used for Service Cloud Voice to also be used for SMS, so dual-functionality essentially (Voice & SMS). If we didn't set up SMS via AWS, could we designate the Amazon claimed Voice phone numbers to an Enhanced Messaging channel in Salesforce to use their SMS capabilities?

 

I feel there are likely a lot of no no's to the latter approach, mainly being the integration piece and phone call disruption based on the number also being texted into by other customers. Anybody out there run into documentation or a personal use case they've explored more into this? Looking for any answers that may lead us down the next best path.

 

TIA!

8 answers
  1. Sep 10, 2024, 5:31 PM

    Digital engagement can use number provisioned by AWS. Submit a case with Salesforce to provision them in your org. There are a number of registration steps to take as well when using these numbers.. 

     

    Integration wise once the number is provisioned, Service Cloud Voice and Digital Engagement can support the number without conflicts. 

0/9000