A lot of enterprises depend on Salesforce for many of their business processes ranging from marketing automation to sales process management. They don’t’ all use Salesforce. Each enterprise use tens of different apps and nearly every enterprise’s top app selection criteria is the app’s capabilities to connect with other apps, and in many enterprise’s cases, the capability to integrate with Salesforce. This also gives ISVs with integrative products a competitive edge. In this post, we will take a look at different approaches an ISV could take for providing Salesforce integration support for their product.
Independent Software Vendors And Salesforce
I remember a 2014 study according to which an enterprise on average use 508 different applications, most of them having cloud-based data sharing capabilities. Though in the past 2 years this number would have gone down considerably, an enterprise still uses a hundred different applications. Also, the focus has also shifted from ‘number of apps to’ an integrated solution environment. What that means is that enterprises now invest in solutions that can do many tasks instead of a single specific one, and should be able to directly interact with other software without a help of 3rd party tool.
Even though there are many different ways an application can be integrated with salesforce, there are four major approaches an ISV can take in when providing support to their customer in integrating with Salesforce.
- Self Hosted Custom Integration Adapter
- Forcedotcom Based Integration App
- Direct API and Class-Based Integration
- Sitedotcom Based Web Service Integration
Each one has its pros and cons and every software vendor needs to analyze their requirements, their client’s requirements, and costs involved before finalizing an approach. To make the matters simpler for the ISVs, in this post we would be comparing each on the basis of development efforts, deployment efforts, Scalability, Flexibility, and Salesforce restrictions.
Self Hosted Custom Integration Adapter
Custom Adapters, as the name suggests, are completely self-developed and hosted integration software whose main aim is to allow two-way communication between Salesforce and the Customer software. Usually, these type of adapters are built using technologies like JAVA and .Net, and hosted on similar environment, but new technologies like NodeJS and cloud servers are taking their place.
Development Efforts
Compared to other approaches, this one is the most difficult approach. Not only do you have to develop a complete software from the scratch, you also have to deploy it on your own servers, maintain it, and scale it. Security from both ends is a challenge as you have to keep in mind the security of both the systems, the ISV product, and Salesforce. Development release, on the other hand, is faster. Configuration efforts on Salesforce end on the other hand is quite fast. You can release the app as a package and allow easy installs, or you can design and develop the App to simply communicate with SFDC using API callouts. Configuration may require a Salesforce expert but it is a one time job.
How Real Is The Real-Time
The word realtime is often misunderstood. For some realtime means data exchange every other hour, for some it means data sync at the very instant. Custom adapter are not 100% real-time i.e. you have to run a frequency based job at the adapter end to check the disparity between the application and Salesforce data. A higher frequency means mean more API callouts per day and more running jobs per hour on your server, whereas a low frequency means your data is less ‘real’ time.
Flexibility And Scalability
As the whole integration application is your own end, you can easily add more features to the app, or upgrade the technology without large downtimes. Upgrading will not involve considerable development support at the client end, however, you may have to provide some technical expertise in re-configuration. On the other hand, you can easily provide integration support to a large number of clients at fewer development efforts.
Revenue And Costs Involved
As you are hosting the solution on your end, you would also have to bear the hosting costs in addition to the development costs. Again, as the product is your own, you are responsible for its promotion. Most software vendors include integration adapters as part of the package but you can be as innovative with your pricing as you want.
Forcedotcom Based Integration App
This approach is basically the same as above mentioned one with one major critical difference, instead of a self-hosted server platform, we would be using SFDC Forcedotcom cloud platform and SFDC technologies to develop, deploy, and run the integration app. Forcedotcom is Salesforce native app development cloud platform. You can package the integration adapter as a native app package (managed or unmanaged package app), and can even launch these apps on Salesforce AppExchange. Also if properly developed (both AppExchange app and the integrated software), it is not even necessary to host the app. If your external software has properly developed APIs, AppExchange installation will make the necessary changes in client’s Salesforce instance to connect Salesforce through these APIs without any need for developer level coding.
Development Efforts
Development efforts are comparable to the self-hosted custom adapter approach, but since you are using the Salesforce platform for both development and/or hosting, your time gets cut down a little. Packaging a Salesforce-based app is also easier. However, if you are planning to release the app on AppExchange, which we would highly advise you to do, you will have to invest a lot of effort on making the app AppExchange ready. I suggest reading through our previous posts on AppExchange.
If your app is on AppExchange you and your end client also save a lot of time on installing and configuring the integration at Salesforce.
How Real Is Realtime
The ‘real-timeliness’, if that is a word, is similar to Self Hosted Adapter approach. Time-based jobs will find any data differences and will update data on both sides. You can include triggers in SFDC logic to make sure that any change in SFDC org is instantly reflected in all areas.
Flexibility And Scaling
Your app’s scaling and flexibility in this approach as well depend on your coding skills. Forcedotcom platform gives a lot of options for scaling the application so that’s a plus point. If you list your app on AppExchange your release cycle may extend because of salesforce review processes but not by much. The appexchange listed app also saves you the trouble of manually updating the app integration at each client end. Once you upgrade the app at AppExchange, app users can easily upgrade their apps from their instance itself, unless that is your upgrade don’t induce some radical changes which may require expert deployment.
Revenue And Costs Involved
Forcedotcom apps are a little bit expensive to develop because they take more time in making sure that it is up to Salesforce security standards. However, they make up for the fact that you get a free entry to a highly visible Salesforce AppExchange platform. In fact, many ISVs have adopted the AppExchange platform as their additional revenue generation platform by launching paid Salesforce apps.
Direct API And Class-Based Integration
This is the easiest approach to integrate two different solutions. Instead of developing/deploying an app, if the external software has compatible APIs we can directly integrate Salesforce with the solution. So a common guideline for ISVs is to develop and provide a very robust set of APIs to allow easy integration with Salesforce and other software. It’s very beneficial in long terms.
Development Efforts
Development efforts are directly dependent on the complexity of APIs available. If you are going for a complex integration with lots of different data integration points, if will naturally require more development efforts. However, by average, a typical enterprise-level integration through direct API communication require considerably fewer development efforts. But the problem comes when you to transform and then transfer data, or there is a clash of data standards, or APIs are just not advanced enough.
The problem, however, comes at the client side. You would need considerable development efforts to write custom apex code to integrate through APIs. If your client base is small and you don’t want to promote the integration, then this approach is very beneficial. Otherwise creating an AppExchange app that will automate the integration process would be more beneficial, both in terms of cost and time.
How Real Is Real-time
These type of jobs are usually dependent on triggers. A user action will trigger updating of data and at both sides. So we can say that the approach is a very real time in this aspect. The problem comes around transformed data. If the entered data has to be transformed either at Salesforce side or at external software side, updating/syncing it in real time becomes a challenge.
Flexibility And Scaling
Flexibility again depends upon the level of complexity of APIs at both sides. If a type of data transfer is possible, then it’s easy and direct, if not then you have to take a totally different approach. Scaling is easy. However, you have to take into consideration Salesforce API limits. Check out this page for more info on API limits.
https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm
Revenue And Costs Involved
If direct integrations are available and usable, then direct API integrations are the cheapest approach. However as stated earlier, if you would have to deploy on multiple instances of multiple clients, then it’s beneficial to go the app way.
Revenue And Costs Involved
So as you may notice, all approaches have their pros and cons. We usually emphasize more on AppExchange based and API based integration to ISVs mainly because it’s easier to scale, distribute, and can be a source of revenue.
Apart from these, there is an alternate approach: via Sitedotcom based web integration. This involves creating integration scripts that run on custom Visualforce pages, which are in turn deployed at client side Salesforce instance. This approach is practical in some use cases but on a larger scale it’s full of security nightmares, require deployment efforts at each client instance, difficult to scale, difficult to upgrade, and prone to errors. So we usually don’t take this integration approach.
Wanna grab some Extra Knowledge about Salesforce? Here you go. 😉
Pratyush Kumar
