(2022-Jan-19) David Eldersveld once said that a “cool solution is a completely insecure solution” - David Eldersveld on Twitter. That puzzled me, but only for a little while, since I completely agree with him. It’s easier to create a solution prototype that doesn’t meet most of the security requirements and then present it as a minimum viable product. It’s harder to take a different, more demanding path to create an IT solution and apply necessary security guidelines.
Image by Daniel Nebreda from Pixabay
Microsoft documents really well all the technical details on how to integrate Salesforce datasets using Azure Data Factory (ADF) and making them available for further processing - https://docs.microsoft.com/en-us/azure/data-factory/connector-salesforce?tabs=data-factory. This document covers the usual set of capabilities, definition of a linked service to Salesforce, data copy task along with explaining its source and sink datasets.
Creating a linked service to a particular data source is very important, it’s like oxygen that your data load pipelines won’t live without or a rock foundation that your data solution requires to withstand all windy and rainy climate transitions.
Salesforce linked service in ADF is no different from others and contains both required and optional parameters:
In a less secure Azure environment, you can simply provide Salesforce URL, user name, password and security token along with Azure Integration runtime to create a successful authentication in your Data Factory.
However, if you read that “fine print” section of the security token definition, you may find additional information on how to bring extra security to your ADF and Salesforce connection, by adding your integration runtime's IP to the trusted list on a Salesfore side.
This will eventually turn your Salesforce and Azure Data Factory data integration into a secure IP to IP communication channel, as well as remove a need to provide a security token during a connection.