Salesforce Integration- Salesforce Platform #3

What is Salesforce Integration?

In my prior post, I focused on what it means to be a Salesforce Business App Developer, and looked at some key native application development capabilities of the Salesforce Lightning Platform. In this post, I'll look at opportunities for becoming a Salesforce Integration Developer—and how the platform provides a standards-based open architecture to promote and allow integrations across an enterprise system landscape to one or more systems and applications, both on-prem and cloud-based.

Why Do Salesforce Customers Need Integration Developers?

While a Data or Business Analyst can typically define the requirements around any particular integration, the implementation of any sophisticated integration usually needs a resource with a developer mindset and broad technical experience. Opportunities for Integration Developers on the platform not only include ongoing integration projects, but also an almost never-ending need for legacy system data and process migrations.

Yes, the Salesforce platform provides multiple no-code feature sets and a myriad of point-and-click tools to support integration. However, while these tools provide non-programmers with great leverage when interconnecting systems, sooner or later many customers will require highly technical and programmatic customizations as their systems scale out.

Let’s look at a few different types of integrations an Integration Developer might perform on the Salesforce platform—data, code, and Salesforce APIs—and some of the details behind how they work. (You can review some of the common platform integration patterns and best practices in this document, including the images below, courtesy of Salesforce.)

Data Integrations

The most common integrations are those importing and exporting data. For many years the original multi-platform Java-based, data import/export desktop application (AKA Dataloader) provided for free by Salesforce allowed non-programmers to push and pull data from any Salesforce org without writing a line of code. The newer version Dataloader.io is cloud-based, provisioned as a freemium model thanks to the recent acquisition of Mulesoft by Salesforce. It is also partly built into the Salesforce Lightning UX; no code needed.

In addition, many third-party tools have been around for years, some capable of complex data integrations or Extract Transform and Load (ETL) orchestrations that can be built by Salesforce Admins and Business Analysts without a single line of code.

Sooner or Later Data Integrations Require Code

However, both simple and complex custom integrations often require processing capabilities beyond what these tools can provide. While many of the built-in mechanisms allow point-and-click configuration, an Integration Developer is often needed eventually.

Here are a few examples:

External Objects - user-configured custom data tables that act as proxy objects connected to an external data source using the open OData protocol. While the target data doesn’t get imported into Salesforce, it is virtually accessible through the established secure connection, and the data can be searched, read, and changed from within Salesforce. You can overcome the limitations of the point-and-click functional capabilities by using custom Apex. You can also use Visualforce or Lightning Web Components for more sophisticated custom user interface requirements. So even though the core mechanism is based on a no-code foundation, complex customizations around the external data absolutely require programmatic skills.

Outbound Messages - a popular legacy feature allowing no-code workflow automation to send outbound SOAP notifications to external systems. These workflow actions are configured with a point-and-click wizard, and allow for generating related WSDL XML documents containing the integration details. However, target listeners or services are required to consume the notifications, which are typically coded.

Platform Events - a highly-scalable message bus built into Salesforce. It allows asynchronous messaging across various no-code automation tools and Apex automation inside a Salesforce org. However, in order to extend beyond any org’s system boundaries, these notifications must typically be consumed by external applications using CometD and the Bayeaux protocol, familiar to many traditional programmers. Inbound event notifications from external apps are made by calls to the Salesforce REST API.

Apex Email Services - a way to manage both inbound and outbound email to and from a Salesforce org using custom email addresses routed to custom Apex classes. While the service configurations are indeed point and click, they’re useless without associated Apex code to manage both process and content.

Code Integrations

Next let's look at building integrations with code. Custom programmatic integrations also need the support of Integration Developers. While I discussed Apex at length in my last post, what I didn't mention was that the language supports many built-in features that support web-based inbound and outbound integration service calls.

Processing Inbound Calls

Apex supports the declaration of classes and methods that provide custom (as opposed to the automatically provided) SOAP or REST-based web services. WSDLs are provided for SOAP services, and REST classes can be configured for URI routing, while their methods can be bound to standard REST verbs such as GET, POST, and so on.

These service methods can be called as requests from external systems once authenticated through the API layer. (See below for more information.) The power of Apex can be leveraged to perform or invoke required processes, or to fetch and shape any Salesforce data to pass back in a response.

Processing Outbound Calls

Synchronous or asynchronous Apex methods can make web callouts to whitelisted external systems. The language has many built-in class libraries that support web communication protocols, encryption, and help to manage document parsing and construction for both XML and JSON.

Authentication and Security Mechanisms

Security is a critical component, and also a key part of Trust—one of Salesforce's core values. All integrations require secure connections, so naturally the Salesforce platform provides a collection of no-code mechanisms to manage granular authentication, authorization, and identity.

While these mechanisms are designed for point-and-click configuration, a deeper technical understanding and perspective is often necessary to safely and effectively configure and leverage them for complex integrations. Some of these mechanisms have programmatic aspects for use in Apex solutions, and Salesforce developers need to be familiar with them.

OAuth is configured inside Salesforce with Connected Apps, providing a standard and flexible protocol for external systems to authenticate and authorize at both an application and user level. The wide variety of OAuth flows (and their many permutations) cry out for developers to manage.

Remote Sites, Named Credentials, and Auth Providers are mechanisms that allow Apex callouts to reach external systems. From simple endpoint whitelisting to more complex programmatic access to securely stored authorization tokens, the more complex aspects of these tools often need programmer expertise to master, especially when they extend into Apex code.

There are many other tools such as Signed and Unsigned Certificates, Two-Factor Authentication, Single Sign On, and Identity configuration—all of which benefit from developer expertise.

Ever-Evolving Salesforce APIs

Lastly, let's look at APIs. I won't delve into the details of the many APIs available to connect to any Salesforce org. However, I’ll break down what’s available to an Integration Developer at a high level.

At its core, Salesforce is a database with automation processing capabilities. The system automatically provides SOAP WSDLs supporting secure inbound calls from external systems. Such calls can be made to execute CRUD operations against all core standard and custom objects, plus some limited administration processes.

Salesforce was an early adopter of an open API architecture, and their integration capabilities have continued to steadily evolve since the introduction of their SOAP API late in 2008. Its release was followed by the introduction of a REST API based on Web 2.0 standards in 2011. It typically evolves in its capability with each release and provides a collection of out-of-the-box data services including CRUD access to all standard and custom objects, as well as activation of various logic actions.

Other URI endpoints support bulk processing of millions of data records, and there are dozens of other built-in services supporting various features. This includes access to much of an org’s metadata controlling UI, navigation, and automation logic and more.

Once authenticated, the security mechanisms mentioned above (such as the Connected Apps) allow security at both application and user levels. This extends right down to the field-, object-, and record-level data security and logic actions.

In my view, to effectively leverage the vast capabilities of the platform APIs, resources that have basic familiarity with software development, web services, and most importantly, a deep understanding of the Salesforce architecture are required. All in all, there’s plenty for integration developers to chew on and master when it comes to integration on the platform.

Up Next: Extending the Platform with a World of Applications

As Salesforce has grown over two decades, limitations of the native CRM applications such as Sales Cloud and Service Cloud have resulted in the acquisition of products designed to effectively extend the features and capabilities needed by the growing customer base. These include products supporting marketing, eCommerce, analytics, and more.

Some of these applications are built on the native platform as packaged extensions, while others remain on independent technology stacks. While the former have direct access to customers’ Salesforce data and logic, external products must use APIs and connectors to integrate any data exchange or process activation. Many also provide programmatic API access. Again, more opportunities for the integration developer.

In my next post, I’ll summarize some of the key applications that extend the Salesforce platform, and explore some of the opportunities for developers to master the integration aspects as well as other programmatic needs of these products. I’ll also touch on the Heroku platform, native mobile app development, the Internet of Things (IoT), and Mulesoft, a Salesforce product used to create APIs to bridge on-prem or cloud systems including Salesforce. I hope you’ll continue to join me on this Salesforce Developer journey.

Thanks to Don Robins for his kind permission to publish this article.