6 results found

1. Add ANI and Call Direction to “Engaged / Call Connected” Webhook Payloads

   Short description of the issue:

   Balto requires ANI (caller phone number) and call direction (inbound/outbound) to be included in the Engaged / Call Connected webhook payloads from RingCX. This data is essential for triggering Balto’s real‑time guidance, enabling customer identification, and unlocking downstream customer history and analytics workflows for shared customers.

   Background / Context :
   Balto integrates with RingCX today using call event webhooks, not gRPC streaming. The webhook events are used to:

   • Turn the Balto application on when a call is engaged
   • Begin recording and analyzing audio locally within Balto
   • Turn Balto off when the call ends
   • Capture call metadata such as RingCentral Call ID, Queue/Campaign, and Disposition
   • Currently, the Engaged / Call Connected webhook payload does not include ANI, and call direction is not explicitly included. DNIS is available in some cases but is insufficient on its own.

   Balto explored a gRPC-based alternative, but it is not viable for their use case because:

   • They do not need audio streaming from RingCentral
   • They require event reliability (webhooks are preferred)
   • gRPC streams cannot be reliably recovered if the connection drops, introducing risk of lost events
   As a result, enhancing the webhook payload remains the preferred and required solution.

   Requested Enhancement :
   Add the following fields to the Engaged / Call Connected webhook payload:

   • ANI (Caller Phone Number)
   • Call Direction (Inbound / Outbound)
   These fields should be consistently included for all relevant call flows.

   Priority Recommendation
   High – Partner‑requested, customer‑blocking, and tied to revenue‑impacting integrations across a large shared customer base.

   Short description of the issue:

   Balto requires ANI (caller phone number) and call direction (inbound/outbound) to be included in the Engaged / Call Connected webhook payloads from RingCX. This data is essential for triggering Balto’s real‑time guidance, enabling customer identification, and unlocking downstream customer history and analytics workflows for shared customers.

   Background / Context :
   Balto integrates with RingCX today using call event webhooks, not gRPC streaming. The webhook events are used to:

   • Turn the Balto application on when a call is engaged
   • Begin recording and analyzing audio locally within Balto
   • Turn Balto off when the call… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Integrations & APIs  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. MS Dynamics - Auto Complete Phone Calls

   With Microsoft Dynamics, phone calls are logged but are in an "Open" status by default. This skews reporting in Dynamics if an agent forgets to take the extra step of marking the call as complete. In a high volume or fast paced environment, agents may receive a another call right after dispositioning/wrapping up the previous call and forget to mark as complete later. If we can have a setting to enable or disable calls to auto-complete at the account level based on preference, that would help keep Dynamics reporting accurate and simplify the agent workflow

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Integrations & APIs  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Mandatory Name and Related To fields on the RCCX for Salesforce

   Make the Name and Related To fields on the RC widget on Salesforce mandatory

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Integrations & APIs  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. API

   Proposed Enhancement: Smarter Call Availability Signaling for Lead Vendor API
   We would like to propose an enhancement to RingCentral’s lead‑vendor call routing API to better support high‑volume call centers with large agent teams.
   Currently, when a lead vendor attempts to deliver a call, the API only performs a fixed number of availability checks (approximately 10 pings). In environments where a call center may have dozens or even hundreds of agents, this limitation creates a bottleneck and increases the likelihood of failed or prematurely rejected calls — even when agents are actively becoming available moments later.
   For larger call centers, this approach does not scale effectively.
   Problem

   Call centers with fluctuating agent availability need a real‑time, state‑aware mechanism to manage inbound vendor calls.
   A fixed number of pings does not account for:

   Large agent pools
   Rapid availability changes
   Call centers operating at near‑capacity throughout the day

   As a result, vendors may attempt to send calls when agents are unavailable, or abandon routing attempts too early when agents are about to become available.

   Proposed Solution
   We recommend enhancing the API to support agent availability awareness and dynamic call acceptance logic, including:

   Real‑Time Availability Signaling

   The API should be able to signal to lead vendors whether:

   At least one agent is currently Available and Ready, or
   No agents are available at that moment

   This allows vendors to intelligently decide whether to initiate or delay a call attempt.

   Call Gating / Intelligent Blocking

   When no agents are available, the API should indicate that calls should be temporarily blocked or queued, rather than repeatedly pinging or failing.
   Once an agent becomes available, the API should transition back to an “accepting calls” state.

   Scalable, Event‑Driven Model (Preferred)

   Instead of a limited ping‑based approach, an event‑driven or subscription‑based availability model would allow vendors to poll or receive status updates efficiently.
   This reduces unnecessary retries while improving call delivery success rates.

   Benefits

   Higher call connection rates
   Reduced dropped or rejected vendor calls
   Improved vendor trust and performance transparency
   Better support for enterprise‑level call centers
   More efficient API usage with less unnecessary traffic

   This type of intelligent availability handling would significantly improve RingCentral’s ability to serve large, high‑volume operations and strengthen integrations with lead vendors that rely on precise agent readiness signals.

   Proposed Enhancement: Smarter Call Availability Signaling for Lead Vendor API
   We would like to propose an enhancement to RingCentral’s lead‑vendor call routing API to better support high‑volume call centers with large agent teams.
   Currently, when a lead vendor attempts to deliver a call, the API only performs a fixed number of availability checks (approximately 10 pings). In environments where a call center may have dozens or even hundreds of agents, this limitation creates a bottleneck and increases the likelihood of failed or prematurely rejected calls — even when agents are actively becoming available moments later.
   For larger call centers, this… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Integrations & APIs  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Native RingCX alert notifications to Microsoft Teams (chat & channels)

   It would be extremely valuable for RingCX alert notifications to be pushed directly into Microsoft Teams chats and channels via a native integration.

   Currently, the workaround requires:
   Alert → Email → Power Automate → Microsoft Teams

   This introduces unnecessary complexity, additional maintenance, and potential points of failure.

   A native Teams integration would:

   • Reduce technical overhead

   • Improve reliability and speed of alert delivery

   • Eliminate dependency on third-party automation tools

   • Increase adoption of real-time operational alerts

   Ideally, this would allow alerts to be sent to:

   • Individual user chats

   • Group chats

   • Specific Teams channels

   This would significantly strengthen real-time operational visibility for supervisors and leadership teams using RingCX.

   It would be extremely valuable for RingCX alert notifications to be pushed directly into Microsoft Teams chats and channels via a native integration.

   Currently, the workaround requires:
   Alert → Email → Power Automate → Microsoft Teams

   This introduces unnecessary complexity, additional maintenance, and potential points of failure.

   A native Teams integration would:

   • Reduce technical overhead

   • Improve reliability and speed of alert delivery

   • Eliminate dependency on third-party automation tools

   • Increase adoption of real-time operational alerts

   Ideally, this would allow alerts to be sent to:

   • Individual user chats

   • Group chats

   • Specific Teams channels

   This would significantly strengthen real-time operational visibility for supervisors… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Integrations & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. RingCX API should expose agent statuses (availability and offhook state)

   The RingCX API should expose agent statuses (such as availability and offhook state) in addition to supporting event subscriptions.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Integrations & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating