Rebuilding CloudCall's Salesforce CTI Package for Lightning Experience

The challenge

CloudCall, a UK cloud telephony company, provided telephony capabilities inside 3 CRMs: Salesforce, Bullhorn and Microsoft Dynamics. In Salesforce the product was distributed as a managed package on AppExchange.

The existing package needed a new generation. Its Salesforce backend was due for an overhaul to improve performance and maintainability. And the softphone was a Visualforce page in the Classic sidebar, which looked outdated at a time when many customers were moving from Classic to Lightning Experience, where a softphone belongs in the utility bar at the bottom of the console.

At the same time, the company decided to build one new Angular softphone to serve all 3 CRMs. With a new softphone coming and Lightning becoming the standard, it was the right moment to rebuild the Salesforce package as well.

What I did

I joined CloudCall in-house as Lead Salesforce Developer and led the in-house Salesforce team that owned the Salesforce package, working alongside the product team that built the shared Angular softphone. My scope was the Salesforce side: package architecture, Apex services and REST APIs, releases and the delivery pipeline.

We rebuilt the managed package around Open CTI for Lightning. The Angular softphone now ran in the Lightning utility bar, embedded through an Aura component, instead of a Visualforce page in the Classic sidebar.

Behind it, the package handled the call end to end. An incoming call came through the phone network to the CloudCall platform, which notified the managed package in Salesforce. The agent answered in the softphone, and the package looked up the matching Salesforce record and opened it automatically. The agent worked the call and took notes. When the customer or the agent hung up, the platform closed the session and stored the recording, and the package wrapped up the call in Salesforce: the call activity was saved on the record, and the notes and call data were synced back to CloudCall.

Outbound worked in the other direction: click-to-dial on any record with a phone number sent the event through Open CTI to CloudCall, which placed the call through the telephony network and started it in the softphone. Agents could also work CloudCall dialer campaigns: a list of contacts loaded into CloudCall was dialed automatically, and the next call started after the agent finished wrap-up on the previous one, with each call logged in Salesforce. I reworked the Salesforce backend along the way, so call handling and logging ran faster and the code base was easier to maintain.

Because the package had already passed AppExchange security review in its previous version, the new version could ship as an update of the existing listing without a new review. I ran the releases, and to make them repeatable I set up the delivery pipeline with SFDX for source, GitLab for version control and Jenkins for builds.

The result

• Full rebuild of the AppExchange managed package in ~1 year
• Softphone moved from a Visualforce page in the Classic sidebar to the Lightning utility bar, ready for customers moving to Lightning
• Optimized Salesforce backend: faster call handling and logging, maintainable code
• New version shipped as an update of the existing AppExchange listing through an SFDX, GitLab and Jenkins pipeline

System landscape

Layer	Components
Telephony platform	CloudCall cloud telephony, call recording, dialer campaigns
Softphone	Angular application, Salesforce Open CTI, Lightning utility bar, Aura component
Salesforce package	AppExchange managed package, CTI adapter, Apex services, REST APIs
Other CRMs	Bullhorn, Microsoft Dynamics (same Angular softphone)
CI / CD	SFDX, GitLab, Jenkins, AppExchange managed package releases

Team & duration

~15 months, 11/2017 to 01/2019, in-house. I led the in-house Salesforce team that owned the Salesforce package, working alongside the CloudCall product team that built the Angular softphone.