0

We're working with an OpenCTI adapter that the vendor has open-sourced for us. So we have the ability to customize the dialer page which is by design written in Visualforce. The dialer appears in the Lightning app's Utility Bar. We are trying to make the incoming call process in Lightning Experience (not console) as friendly as possible.

What we'd really love to see happen is, when an incoming call comes in, a second component (built in Lightning) pops up from the Utility Bar. If there's any way we can throw an event that would be received by a Lightning Component that would be great, as we've already proven we can respond to the event by having the Lightning utility pop itself open.

However it seems that the mode in which the OpenCTI dialer page loads does not have access to any methods that can throw application-level Lightning events in Lightning Experience (sforce.one is unavailable, the undocumented SfdcApp is unavailable). The available OpenCTI screenPop method for Lightning Experience covers use cases such as navigation, new record modal, search, but nothing that actually integrates into Lightning's event model to allow us to throw an event without leaving the page the user is currently on.

Any ideas?

0

This is an older post but in case anyone else comes along or if it still pertains to you, you could use Salesforce Platform Events and cometd for this. When you receive an incoming call you can create a new (Incoming Call) event and publish it. In your lightning component you would load cometd and subscribe to the platform event (Incoming_Call__e). Whenever that event is published you would receive notification and would be able to handle it in the component.

  • The idea is that the OpenCTI widget is already running in the same browser and it just needs to communicate with a Lightning Component. What you're describing would require the OpenCTI widget to make a server-side call to publish the event so that the server can push it back to Lightning. And the use case was for potentially hundreds of clients, who should not be seeing each other's pushes. In the end I found that the best approach would be to do a plain window.postMessage but ultimately our client dropped the requirement that necessitated this post. – Charles T May 31 '18 at 23:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.