#Omni Channel16 discutindo

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

We have a recurring issue where Cases are reassigned to a queue (a queue called West), seemingly automatically and at random.  Today, we had this happened to eight cases in the course of just a few minutes. 

We have one Assignment Rule that assigns Cases to the Escalation queue if the words "You have new held messages" appear in the Subject of the Case.  These words do not appear in any of the Cases that were reassigned. 

Our Escalation rule, again, only assigns Cases to the Escalation queue if certain words appear in the Subject of the Case.  None of the Cases that were reassigned include any of the words indicated in the Escalation Rule. 

We removed all Skills-Based Routing several months ago. 

We have ONE flow on the Case object.  It is a Record-Triggered, Create Only Flow.  The Cases are being re-routed long after creation.  One of the Cases rerouted today was four days-old.  This Flow looks at the Team field on the Account related to the Case.  If the Team is National, the Case is assigned to the National queue.  If the Team is DMR, the Case is assigned to the DMR queue.  f the Team is Southeast or Northeast, the Case is assigned to the East queue.  Everything else is assigned to the West queue (including any Cases with no related Account or any Case where the related Account has no team). 

The most common reassignment is from the East queue to the West queue.  However, Cases are reassigned from other queues and from individuals to the West queue.    

Today, one of the Cases that was reassigned had been assigned to an individual who was not working today.  The Case had not been updated since Friday. 

We only have one service channel.  We only have one agent per queue.  All of the Routing Configurations are the same.  All of the queues are the same. 

I checked Scheduled Jobs and none of them ran close to the time that the reassignment happened. 

I have been searching for months and cannot find any Apex Trigger or Class that changes the owner of a Case. 

The change appears to be made by our Service Account Admin user.  This user is used to make all kinds of updates and changes throughout our org.  Trying to sort through Debug logs has been impossible. 

Can anyone think of any other way to troubleshoot this issue? 

Hi Everyone, 

I know that there is currently a live idea on this topic but i just wondered if anyone had found a work around to this blocker? 

I know that tasks can be adding a Queue (list view) in lightning but i need to have the tasks show up in the Omni-Channel queues so that they can be assigned out to agents at our Contact Centre. 

All of our tasks are related to cases but we don't want the tasks to be tied to one single agent (owner) they need to be in the Omni-Channel so that the tasks can be picked up by the next available agent on the day the task or tasks are due. 

I hope that makes sense. 

Thanks 

Eric 

Issue:

When a consultant clicks 

Accept on a routed Case work item, the AgentWork.Status field is moving to Canceled instead of Opened/Assigned. This is happening consistently, not as an occasional glitch.

The practical impact: on cases that get handed off between multiple consultants before resolution, only the finalconsultant (the one who closes the case) ends up with a usable HandleTime value. Every earlier consultant who worked the case has their AgentWork record sitting at Canceled, with no AcceptDatetime-to-CloseDateTime window ever calculated — so their actual time on the case is invisible in reporting, even though they clearly worked it (case comments/emails/status changes during their ownership window confirm this).

What I've already ruled out:

• Confirmed we're on Enhanced (not Standard) Omni-Channel via Omni-Channel Settings
• Confirmed Status-based capacity model is in use on the Case service channel
• Confirmed every Case Status picklist value has a mapping (In-Progress/Paused/Completed) — no unmapped values
• This isn't a competing-routing/race-condition scenario — it happens even on cases routed to a single agent with no other agents contending for the same work item

Expected behavior:

Accepting a work item should set AgentWork.Status to Opened (with AcceptDatetime populated), and HandleTime should be calculated independently for each consultant's own Accept→Close window when a case is transferred/reassigned between them — not just for the last one. I can see that throught the case value changes, the consultant spent 25mins on the case before moving to a "waiting for customer" status and then the last agent picked this up and closed it which is tracking the AHT.

Questions for the community:

1. Has anyone else seen AgentWork.Status go straight to Canceled on Accept under Status-based capacity, despite a fully mapped Status field?

Any pointers — especially from anyone who's hit this post-migration — much appreciated. 

Previously I can be able to login amazon connect SAML instance with salesforce user.  

But now Unable to login SAML instance of amazon connect with Salesforce user. Setup>Partner Telephony Contact Centre> Open YOUR Contact center > Click 'Telephony Provider Settings'. when clicked the below page appear.

In the SCCAC contact center connected with above SAML connect instance, active status achieved in omni channel when I login with amazon IAM user(not salesforce contact center user) in SAML connect instance in same window of browser, otherwise showing Log into Omni-Channel failed.

When the status is active 

• The Incoming Voice call is not receiving in the omni channel where the same configuration worked before.
• But the outbound calls are made with the omni channel and working fine.

What is the possible fixes for the above problem.