Designing a Customer Portal on Top of Salesforce Data
UPSTACK brought on Def Method to develop a web portal for their customer services team that relied on data from their Salesforce instance.
Web Development, Data Engineering
Ruby, Rails, TypeScript, React
Ruby, Rails, TypeScript, React
Decoupled end-user application from reliance on changing Salesforce schemas reducing development efforts to maintain web application
Reduced the time taken to generate reports from up to an hour to less than a minute by removing latency caused by translation services
Reduce monthly costs by eliminating the need for commercial alternatives such as FiveTran, HighTouch or Heroku Connect
UPSTACK is a provider of end-to-end customized IT infrastructure solutions. They assist companies with network connectivity, cloud services, cybersecurity, and colocation services. Through a team of partners they help clients evaluate their existing solutions, and provide recommendations to upgrade and modernize their network technology. An experienced customer service steps in to manage and deliver the defined solution - from negotiating with vendors, managing installations and disconnections, and ensuring the final solution is up and running.
UPSTACK contacted Def Method to help build an internal portal that would assist their customer experience team and their sales teams to streamline delivering on technology solutions to their clients.
UPSTACK was looking to build a customer portal that would allow their internal teams to service customers by providing customer account information such as upcoming installs, expirations and logged support tickets. It would also provide the Sales team with the ability to generate custom quotes. However, the initial version of the web application was reliant on obtaining the necessary data from Salesforce via Salesforce Rest APIs, which made it prone to break with any changes made in Salesforce. Any issue with Salesforce caused downtime for end users, and required engineering time dedicated to fix the issue and rebuild the lost data. Additionally UPSTACK’s reporting service was also pulling and transforming data directly from Salesforce using an ETL service before generating the reports, resulting in inexpedient delays in obtaining business critical reports.
The Def Method team encouraged UPSTACK to move away from a Salesforce-first mindset and consider building a bi-directional sync between Salesforce and their postgres database. Their customer portal and reporting engine could then rely on data from the postgres database. By decoupling their app from Salesforce, changes in the Salesforce schema would no longer cause downtime in the app. Additionally, reporting was now much faster with access to near-real-time data from the postgres database. With the burden of syncing now residing in a translation layer, engineering could much more easily reprocess data syncing when issues arose.
To sync Salesforce with the postgres database, our team experimented with multiple approaches to settle on the one that worked best. We explored using AWS S3 as a middleware to capture and process events coming in from Salesforce and from the postgres database but found the syncing wasn’t completely reliable. We then looked into using Appflow and HighTouch to sync Salesforce and the postgres database. While HighTouch worked well to send data to Salesforce, we still lacked a way to ingest data from Salesforce. We eventually settled on building a bi-directional sync between Salesforce and the postgres database that gave us near instantaneous updates between the two systems.
Through experimenting with different means of syncing data, Def Method was able to provide a solution that was robust, fast, and cost effective over the long run. UPSTACK has a robust customer support portal with real-time data that its internal customer support, sales and account management teams can use to provide excellent service to their customers. And their data team can now run analytics on all their data which was virtually impossible previously when they had up to an hour lag in reports generating.