I was recently challenged with an integration project to connect an existing CRM platform into a new instance of Salesforce. At first I was a little hesitant having never seen, used, or developed anything for Salesforce before; however, I found the feature documentation for the platform very helpful and was able to get a head start from the hundreds of coding examples available on the net.
In order to meet client requirements, I wanted an event based system that didn’t rely on any running servers / infrastructure to keep cost and maintenance to a minimum. The project also required communication between the systems with the addition of notifications to Slack, a communication tool. With those thoughts in mind I settled on an integration leveraging Salesforce triggers, which would send events to an AWS Lambda function via API gateway. Within the Lambda function I could map fields and coordinate information to the existing platform while also sending communication to Slack letting users know new data has been added.
Firing up the official Salesforce developer documentation I began learning what options were available to architect the integration. The documentation is extensive, well written, and helpful, assuming you can find what you’re looking for. Naming convention and nomenclature took some getting used to, plus the public documentation is more a list of articles and you really need to know what feature you’re looking for in order to learn about it, making this a bigger challenge than expected at first. I found the details for the trigger functionality and decided indeed this was the best route to take.
While the organization of the documentation leaves something to be desired, the actual functionality of all the Salesforce features I used was well implemented. From the built-in interface functionality for changing most settings, to the inclusion of custom fields you have a lot of flexibility, but again, I was left to figure out how all these interface features work.
When I finally got down to writing my first line of code, enter the customer Salesforce language APEX. Nothing to fear here though, APEX is basically a form of Java and there are a ton of examples online for doing most or typical logic needs. I had little issue figuring out the syntax. Understanding how and where to write my APEX code within the Salesforce universe was another story. My first attempt was to write a test trigger in our new environment just to see how things work, only to be completely rejected when trying to save. Turns out Salesforce requires you to write all code changes in a sandbox environment, and then follow a somewhat heavy publishing process which can be daunting when your production environment isn’t actually in use. While I may be complaining about this as my first impression upon further reflection I realized this is really a best practice so I won’t harp on it but it does show the lack of flexibility the environment has over developing in your own space and making your own rules.
Cloning my sandbox environment was lengthy, but when completed, I was finally ready to write some real classes and triggers. Writing functionality to call our AWS API Gateway was challenging. I learned Salesforce has some strict requirements around outbound API calls and how they fit into a class. While the requirements are easy enough to find, a solution to write the call while meeting those requirements is nowhere to be found. Enter google! Through a lot of searching, reading and research I ended up developing a solution based on several Stack Overflow posts from people with similar issues. While the triggers are very straightforward to write there is potential trouble is handing bulk updates, which can overload the internal query limits.
This leads me to my next challenge, limits! Salesforce puts limits on most things. I guess this is the price you pay to play on another platforms servers but I have to say the API limits that Salesforce implements are quite annoying. They implement a hard limit of API calls based on the level of your account and if you go over during a particular day, it physically cuts off API calls…which will break everything. I understand limits are part of the Salesforce business model, but I’m surprised there’s no option for overage penalties so your applications still function preventing potential un-wanted downtime.
Overall, the Salesforce aspect of the integration was relatively easy. The tools and functionality that are available make most things simple, even though some of the strict coding requirements initially slowed me down. The difficulties caused by Salesforce paled in comparison to the effort required had I attempted to build an entire platform from scratch. In the end I discovered while Salesforce is far from a silver bullet solution it is for the most part thoughtfully constructed, documented and could serve as a solid base for a variety business solutions.
For this project, the client now has a fully functional Salesforce interface which communicates with their existing CRM, providing critical data in real time to all users. This system has allowed their teams to work faster and provided more visibility into their sales and business processes.
As UDig Innovation Studio engineers we’re constantly challenged with such tasks and given the freedom to dig in and be creative. While it can be challenging, the support of our talented team provides an environment where I can learn and explore new technologies, while delivering successful projects.
