#Messaging5 utenti parlano di questo argomento

I've set up an Enhanced Messaging LINE channel in a Sandbox (UAT) org following the official setup guide (service.messaging_line_create) step by step, but inbound LINE messages never create a Messaging Session in Salesforce, and I've exhausted every troubleshooting avenue I can find. 

Setup: 

Enhanced Messaging LINE channel, Omni-Channel routing to a Queue that supports Messaging Session 

Webhook URL correctly configured in LINE Developers Console → clicked Verify → Success 

"Use webhook" = On, Auto-reply and Greeting messages disabled in LINE 

Channel Activated in Salesforce, Omni-Channel status = Online/Available 

Refreshed the channel connection (re-authenticated Channel Secret/Access Token) — no change 

What I've checked, all clean: 

LINE Developers Console → Webhook errors: 0 errors (with Error statistics aggregation on) 

LINE Verify: consistently returns Success 

Salesforce webhook endpoint (…/commongateway/line/ucom-message/{platformKey}) reachable externally, returns HTTP 405 on GET as expected for a POST-only endpoint 

MessagingSession and MessagingEndUser: 0 records, ever 

Debug Logs (trace flag on the "Automated Process" user, SFDC_DevConsole level, active during every test): 0 log entries generated, even right after sending fresh test messages 

Tried to check the "Enhanced Messaging Log" mentioned in some docs, but couldn't find it anywhere in Setup Quick Find in this org — does this require a specific permission, license, or release version to appear? 

Since LINE reports successful delivery (implying it got a 2xx response) but Salesforce shows literally zero trace of receiving or processing anything — not even an Apex debug log — I suspect either a silent signature-verification failure on the inbound webhook, or a platform-level issue with this specific channel that isn't surfaced in any UI I have access to. 

Has anyone run into this exact symptom (webhook verified + zero errors both sides, but zero MessagingSession/debug log activity) with Enhanced Messaging? Any pointers on where else to look, or whether "Enhanced Messaging Log" requires something specific to enable? 

Org type: Sandbox (UAT). Channel type: LINE, Enhanced platform. 

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

I was successfully able to setup Messaging for In App and Web in my sandbox and it's working fine. Now I have deployed the complete MIAW setup to higher orgs via VS Code , I was able to deploy all the sites, networks, Messaging Channel, EmbeddedServiceConfig, VF Page etc. successfully.

But I'm facing error while publishing the embedded service. I'm getting a success mail saying that the site is successfully published but I'm getting below error just after clicking "Publish" :

Something went wrong, Gack ID: 1839136551-31169 (1553746173)

Also, the "Test Messaging" is disabled. The VF page which was created in the previous org , I have deployed that as well and updated all the urls in the page to new sandbox but still it doesn't help. Since it's mentioned that they will create a new vf page , I tried deleting the deployed vf page but still same issue.

Any help would be appreciated. Although I can create a new embedded service manually in the new sandbox but it would be good to fix this. As I have deployed all components , just need to publish it.

#Service Cloud #Messaging Session #Messaging