* Service Cloud Voice *

To fix the issue where the declineCall method fails to trigger in your Service Cloud Voice Partner Telephony POC, first open your active presence configuration in Setup and ensure that the Allow agents to decline work requests checkbox is enabled, as disabling this setting can silently drop decline events. Verify success by reviewing your agent debug logs to confirm that clicking decline successfully fires the event payload back to the contact center event stream. 

Next, inspect your telephony connector implementation code to confirm that the declineCall method is properly bound to the Omni-Channel workspace API event listener rather than an unhandled custom button action. Verify this step was successful by opening your browser console while reproducing the call decline action to check for uncaught JavaScript errors or failed postMessage payloads originating from the partner telephony softphone frame.

Check your Contact Center routing configuration and Omni-Channel Flow logic to ensure that inbound calls originating from an agent's registered phone number or device do not trigger fallback queue routing rules. You should also verify that the telephony provider (such as Amazon Connect) and the associated Salesforce routing flows correctly identify agent-initiated calls and map them to the proper service channel without triggering automated fallback user ownership. 

Then, review your routing configuration in Setup > Omni-Channel > Service Channels and inspect the Omni-Channel Supervisor logs to trace how the call routing attributes evaluate during test calls. Ensuring that your agent's presence status is properly synchronized with the telephony user mapping will prevent the system from defaulting to offline fallback agents and ensure incoming calls connect immediately to the intended available user.

Olá, Danniel!

Esse comportamento pode estar relacionado à forma como o estado do Omni-Channel é mantido entre abas do mesmo navegador. Mesmo com “Don’t automatically log agents in to Omni-Channel on a new window or tab” habilitado, a nova aba pode inicializar o Omni-Channel com um estado diferente e isso acabar sendo refletido na integração com o Genesys Cloud. 

Eu verificaria principalmente:

• Se o status do Omni-Channel muda para Offline somente na segunda aba ou também na primeira.
• Se o Genesys recebe a alteração de presença imediatamente após abrir a nova aba.
• Se isso acontece usando o mesmo usuário/sessão em navegadores diferentes.
• Se o comportamento ocorre também sem a integração do Genesys habilitada, para separar o comportamento do Omni-Channel da sincronização com o CTI.

Se o Omni-Channel permanecer Online na primeira aba, mas a segunda aba fizer o Genesys mudar para Offline, eu investigaria especificamente a sincronização de presença do conector CX Genesys Cloud for Salesforce e a gestão de sessão entre abas.

I’d look closely at whether the value is being populated by the Voice package through the active console context. If the flow is correctly finding the Contact/Lead but the value changes afterward, that timing would be the first thing I’d try to isolate. 

A useful test would be to temporarily remove the custom assignment and watch the Voice Call record through the full lifecycle: call creation → console record context → flow execution → final Related Record value. That should help identify whether the native behavior happens before or after the flow. I’d also check whether the behavior differs between inbound, outbound, and callback calls. 

More broadly, this is a good example of why Salesforce telephony needs to be evaluated beyond just “does it make calls?” The interaction between call context, CRM records, routing, logging, and automation can become important very quickly. I’ve seen this discussed in the context of comparing the different

Hi Emily, 

Root cause of #1–3 (phantom ringing, ringing during calls, ringing after calls end): This is almost certainly duplicate/competing alerting. Genesys's own documentation describes exactly this pattern — when Genesys Cloud is running alongside a WebRTC client (which includes Genesys Cloud for Salesforce), both can independently try to control ringing/alerting for the same interaction, out of sync with each other. That mismatch between two systems each thinking they're in charge of the ring state is what produces ringing with no call, ringing during an active call, and ringing after a call ends — it's a race condition between the two alerting layers, not one system "getting it wrong" on its own. 

Fix: Genesys Cloud → Menu → More → Settings → Notifications. From there: 

- Either mute ringing for alerting interactions so only one client (Genesys Cloud itself) rings, or 

- Have your admin configure/prioritize a single WebRTC client as the designated alert recipient, so Salesforce's embedded client and native Genesys Cloud aren't both trying to alert independently 

This is documented specifically as the fix for "multiple ringings occurring when using Genesys Cloud alongside a WebRTC client" — your exact symptom set. 

Root cause of #4 (output device reverting): Genesys has a separate setting, Play ringtone on separate device, under WebRTC phone settings — when enabled, ringtone playback defaults to your primary speakers regardless of what you've set elsewhere, which would look exactly like "I set it to laptop speaker, it reverts to headset." Check Menu → More → Settings → WebRTC and confirm whether that setting is on — if it is, that's overriding your manual output choice on every session rather than remembering it. 

Both of these are Genesys Cloud client settings, not Salesforce Voice settings, so this is worth looping in whoever administers your Genesys Cloud org alongside Salesforce, since the notification-priority piece is an admin-level config, not something each agent can fix individually. 

Reference: