Pls Check Update in question for answer

I am a newbie to salesforce. After few hours of researching I am able to figure out how can I do basic CRUD Options via rest Services.

Now I am Stuck at how can I link my salesforce data to an external Sql Database, Initial research suggests this can be achieved by Using APex Rest API, but honestly I find the documentation a little tough.

My requirement is whenever a new record is added in Accounts or contacts, a rest Service will be called and data will be saved at external database as well. I can easily save the data but how will i get the data is big question for me. What is the best approach and are their any good examples to follow ?

I know its a broad question, but i just require the initial push.

My effort For CRUD operations

var auth = new Salesforce.Common.AuthenticationClient();
auth.UsernamePasswordAsync(_clientId, _clientSecret, _username, _Password).Wait();

var client = new ForceClient(auth.InstanceUrl, auth.AccessToken, auth.ApiVersion);
Task<QueryResult<dynamic>> results = client.QueryAsync<dynamic>("SELECT Id,FirstName,LastName,Email From Contact");

var contacts = results.Result.Records;
foreach (var contact in contacts)
    Console.WriteLine(contact.FirstName + " " + contact.LastName );
Console.WriteLine("Press Any Key to continue");


Finally Solved it Update Solution Using Soap.(WCF Service)

Link 1 With Callback to salesforce

Link 2 Outbound callout using WCF dotnet Service Soap

  • I just need to know what all to do in salesforce panel to make this possible Commented Jan 8, 2016 at 9:20
  • Finally I was able to do it special thanks to @drakored Commented Jan 19, 2016 at 9:25

2 Answers 2


You don't need the Salesforce REST API for this use case, you need a receiving API on the end of your external database. The code you have is going to call out from the machine executing it and grab the data from Salesforce. That would be reliant on that machine running it regularly and would be more of an ETL style integration than a transactional web service.

To make this a transactional web service you'd need to have a SOAP or REST endpoint hosted to receive the data from Salesforce when changes are made. To implement it you'd need to use one of several methods in Salesforce to trigger app logic from database DML events.

I'll outline the different ways to achieve this type of integration below. If you want to learn more about the different patterns and see which patterns fit the different use cases then I recommend reading the Salesforce documentation for integration patterns and best practices. It includes a matrix that helps you to pick the right integration pattern and provides the different ways that pattern can be utilized in Salesforce.


Outbound Messages (SOAP)

Salesforce provides a point and click solution called Outbound Messages, but it is specific to SOAP (no REST), and it uses a specific schema that provides a session Id so you can connect back to Salesforce via SOAP if necessary.

The developerforce site has an example of how this is done (using Java on the receiving end):


This is a recommended pattern for your use case from Salesforce. I'm not a fan of it because of the lack of a REST capability and the requirement to conform to their WSDL. If you've already got a middleware good at building SOAP services from an existing WSDL this is a good option. If you have to write your own listening service I'd opt for building a REST service and implement it with one of the next patterns.

Apex trigger calling Apex class

Apex has a way to write custom database triggers which can do app logic before or after DML. It can be used to make callouts by passing to an static asynchronous method (@future method) in another class. This method allows you to use REST or SOAP, but requires coding on the Salesforce side.

Here is an example of how to do a REST callout from a trigger:


For SOAP, you'd have to generate an apex class from the WSDL using apex2wsdl and then use the generated stub class to make your callout. Here is the documentation for async callouts in SOAP


Salesforce lists this as suboptimal on the integration patterns documentation, and I can list a couple reasons they might have decided that.

Triggers are a powerful tool and integrated at the database level. Failures in triggers that aren't handled can result in data not getting stored (you don't want to be the guy responsible for Leads not coming in anymore).

Apex doesn't have a built in way of handling failed transactions to the callout. If your transaction fails in the async method for any reason (external issues included), you can't stop the user from committing the data because the process is async from the UI (requirement of triggers to make callouts). To deal with it you need to handle the errors, and queue a later callout. This part can by tricky because @future can't call @future methods. You end up essentially building your own queueing system. There is a lot of work involved to get it right, but it has the advantage of being much more flexible in the web service side; e.g. it can use REST or a SOAP spec that you can alter which is beneficial when integrating with a third party.

Process Builder calling Apex class

A more recent addition to Salesforce is the Process Builder. It has the capability of calling Apex as an action, and allows you to build logic with point and click tools around database actions (DML). This can be used identically to triggers, but requires a little less code. Here is a good blog post showing an example of how to achieve that:


External data connector via OData / Salesforce Connect (formerly Lightning Connect)

This one is not applicable to your use case, but I decided to post it for others facing the same situation with data that is hosted in an external database, doesn't link to a standard object, and not in an existing custom object in Salesforce or one that can be removed and replaced with an external object.

External data sources allow you to create external objects in Salesforce using "connectors". The external objects it creates sync an external data source (as the name implies) with an object exposed in Salesforce. Winter '16 added the capability to make connections bi-directional when using either the OData or the Apex connectors.


OData is a specification that essentially wraps around REST to allow applications to communicate with external data sources (or middleware acting as an OData bridge). The advantage with OData is that it is a standard and the work involved to implement is less. It has the disadvantage of requiring an OData middleware or capability for your database.

Apex Connector Framework was added in Summer '15 and provides a way to build your own connectors for use with the External Data feature. The advantage here is the ability to write connectors in your own code. This opens up the possibility of connecting to non-OData capable systems (or whatever else your mind can dream up that fits within apex, limits, and the interface spec).


This article on the Engineering developerforce blog has a great introduction to the custom apex connectors.


There are some special considerations with Salesforce Connect:

As of a few months ago when I last checked, there was a cost associated with each external data source. Make sure to check that you're licensed for a connection, and check with your Salesforce account manager about pricing if necessary.

Then there is this help article, which outlines a bunch of different limitations with external data sources. There are a lot of things listed and I haven't read into them all yet, but a quick glance spots some critical things to think about. For example, the like operator isn't available in SOQL or SOSL, and aggregates aren't fully supported.


Additional info

I always recommend Trailhead, it's a great resource to learn about Salesforce development, integration, etc. Here is the module for integration:


Another good resource for learning about web services and callouts is the article on developerforce that discusses and provides examples of some of the patterns:


  • What a great answer Sir, Impressed. Commented Jan 8, 2016 at 10:10
  • Regarding Apex triggers: Where do I add triggers in salesforce. What kind of coding is required on salesforce side and how to achieve it ? Commented Jan 14, 2016 at 14:58
  • In the UI you create them from the customize menu under the standard object you want to trigger from or in the create menu on the custom object definition page. It's usually easier to create them from an IDE or the developer console though as you can just specify what object you want to build a trigger from by the trigger definition. Triggers involve apex coding and require caution more than most places because they can interrupt the ability to insert/update/delete records. I'd recommend checking out the trailhead for triggers. It's a great starting point.
    – drakored
    Commented Jan 14, 2016 at 16:46
  • Hello Sir, I understood the basic concept. First I have to create an Apex class on Salesforce via developer console, then I have to make an trigger(When Insert/Update is done on account in salesforce). which send data in json format to My Web API. So is there an example to show how to make the web api in .Net using C# so that i can consume the data ? Commented Jan 18, 2016 at 9:06

What you are doing there is called an inbound call to Saleforce, you actively request Salesforce to retrieve data based on the query.

If you want Salesforce to be proactive in sending you updates to a SQL database you need to do an outbound call. Outbound calls vary from custom callouts using Salesforce's programming language called Apex to configuration only solution called outbound messages. Of course there are other solutions, 3rd party tools that will do the trick but they come at a cost.

Depending on your complexity, you also have to think about security, sending the request via https with some sort of authentication. If you go on the custom callout route you need to consider the various limits attributed with this type of solution, as well as having to build unit tests to assert the behaviour of the code and have a minimum 75% test coverage.

Hope I got you started, once you get your hands into it feel free to come back to the community so we can help when you get stuck.

Apex callouts

Testing Http callouts

  • Very well explained Sir. Is there a simpler documentation to this process Commented Jan 8, 2016 at 9:59
  • Simpler documentation in creating a custom callout ? or for outbound messages ? Commented Jan 8, 2016 at 10:01
  • To fullfill my requirements. To make outbound calls, to sync new entries in salesforce to my external DB. Any video tutorial/ Blog will do Commented Jan 8, 2016 at 10:03
  • OK, Will just go through their documentaion, Thanks for the help. Commented Jan 8, 2016 at 10:06
  • 1
    It's fine, there's nothing bad in having 2 answers plus yours gives a lot more information in how to achieve. +1 for suggesting trailhead where there is a module that can help him start the integration. Commented Jan 8, 2016 at 10:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .