Is there a list of parity differences between PWA and Client for ZCX.   One major item I have discovered is when using custom variables which are configured to display on inbound notification - works as intended within the Zoom client, however in using Zoom PWA - no variable information will display.   

I confirmed that it is being passed as it is displayed in the custom variable section of the engagement tab.

Curious on how to resolved this, but even more curious of other functions not available through PWA.

Hello all,

We are implementing ZCC Chat campaign. We would like to hide the chat widget on the web-site, when the call-center is closed (out of hours) or provide an alternate form to collect the customer's detail and submit. 

Please share your thoughts on how we could achieve this. Thanks.

Anyone can refer a freelancer in Latam a power user of Zoom Contact Center who can help us with a few projects? 
We r seeking someone to deliver fast prototyping and dev work when it comes to deploying IVR - Virtual Assistant and reporting needs. 
Any leads will be appreciated. 

Good day,

I am new to Zoom Contact Center as we migrated over from another platform. I am learning things as I create flows and so far I am liking what I am seeing.

I am trying to set up call routing based on inbound DNIS. These calls don't get routed to agents but to voicemail boxes.  It is an internal messaging system that would send a voicemail transcription to my email. It is something that I am building to learn the features of ZCC. I've set up the inboxes that I need in ZCC and set up the email routing.

My flow has two entry points. In my previous platform, I would use a condition widget that would "listen" for the DNIS and then route the call to the appropriate branch.

My flow in ZCC is configured as follows:

• Start widget which has two entry points. The entry points represent Country A and Country B. This connects to a Condition widget.
• Condition widget
  • Settings tab, the type is set to Variable and the Variable is set to DNIS.
  • Exits tab - Exit 1
    • Variable Condition is set to Equal to and value is the entry point for country A.
    • Exit name is set to country A
    • Map Exit to Skill - nothing selected as these calls aren't being routed to an agent.
    • Next Widget set to SendMedia A.
  • Exits tab - Exit 2
    • Variable Condition is set to Equal to and value is the entry point for country B.
    • Exit name is set to country B.
    • Map Exit to Skill - nothing selected as these calls aren't being routed to an agent.
    • Next Widget set to SendMedia B.
  • No Match set to Hangup.
• Condition widget - Exit Country A is connected to SendMedia A. SendMedia A plays a text to speech prompt. SendMedia A is then connected to Route_to_Country A. 
• Connection widget - Exit Country B is connected to SendMedia B. SendMedia B plays a text to speech prompt. SendMedia B is then connected to Route_to_Country B.
• Route_to_Country A and B are both set up to route to their respective Inboxes.

If I call either DNIS that I set up, the calls are dropping automatically. If I remove the condition widget and call either DNIS, the calls go through. At this point I believe it is how I have the condition widget configured.

Could someone provide insight on what it is that I am missing?

Update --

I am not sure why I can't reply to my own posts?? 

Regardless, I've solved my own issue. In the Condition widget, Exits tab, I set the Variable Condition to "Contains". Republished and everything is routing as intended.

Hi Zoom Community 👋

Zoom has announced updates to IP subnet ranges and network configurations for various services. New and updated IPv4 ranges have been added for Zoom Phone and Zoom Contact Center, with specific ranges for HTTP Call Widget requests in the Flow Editor. Additionally, one IP range (16.63.29.0/24) has been removed from Zoom Meeting and Cloud Room Connector services due to migration to larger contiguous ranges. Network administrators should update firewall and network rules to accommodate these changes. Zoom has also introduced new URLs for client certificate validation, which should be added to network configurations.

US01 outbound (NAT Gateway EIP): Jan 3 2025 5:00PM PST

This change will modify Zoom initial connections for ZP/ZCX from existing NAT gateway IP to BYOIP subnets. There is no expected impact or actions for Zoom customers. However, we wanted to notify you all of this change. Please be sure to follow our network firewall page to do network ACL in your edge devices for incoming traffic.

US01 inbound (NLB/NginxPlus EIP): Jan 10 2025 5:00PM PST

This change will modify incoming traffic to Zoom connections for ZP/ZCX for Network load balancer and Nginx Plus IP. There is no expected impact or actions for Zoom customers. Follow our network firewall page to do network ACL in your edge devices for outgoing traffic.

Please check out the following related status posts to learn more:

Oct 31, 2024: https://status.zoom.us/incidents/9f4msn4t4k57

Dec 02, 2024: https://status.zoom.us/incidents/5nr22yfc2sb

We need your guidance in defining the precise condition that determines whether a call is transferred and answered by third-party call center.

Previously, after discussing with Zoom POC, we decided to rely on the contact_center.engagement_ended webhook. In the payload, we checked the flow_name == ExternalTransfer condition and derived whether the call was transferred and answered by third-party call center.

However, we’ve recently observed a few cases where the above condition was met, but the call wasn’t actually transferred to the third-party center. This is leading to incorrect third-party transfer counts being displayed as part of our various dashboards.

Could you please help us determine the exact condition we should monitor to confirm if the call is successfully transferred and answered by the third-party center?

Our team is running into an issue with agent schedule adherence. When we run the report it does not give us the opportunity to "fix" the historic information. We use this in scenarios such as a call runs long and the agent doesn't go on break at the right time. We wouldn't want to count this against the agent. The only solution we have found is to manually update their schedule for the prior day by using the Schedule adherence report. The problem with this on top of being time consuming, is the report tells us the agent is out of adherence and for how long, but not at what time the exception started. Does anyone have any advice on measuring this?