If you’re reading this blog, there’s a good chance you need to find a way of moving data between Salesforce and a third-party system.
That could be an accounting solution (e.g. QuickBooks), a project management tool (e.g. Workday), or one of countless third-party SaaS apps, systems, and products. It could even be a proprietary app or system that only your organization uses.
Moving data out of Salesforce just once is comparatively straightforward. But there’s a huge difference between a one-time data extraction and a real-time data pipeline that connects two siloed systems. Here, the challenge can get very complicated, very quickly.
So how do you get it right?
When Realtime Data Is Non-Negotiable
There are several reasons why an organization might want to get data out of Salesforce.
Some of these are fairly straightforward. If you’re looking to create backups or compliance reports, for example, a simple point-in-time export should work fine. Effectively, this is a solved problem, and many simple options exist on the market to facilitate this.
But there are also plenty of situations in which real-time data is absolutely essential:
- A retailer manages inventory in an ERP (e.g. NetSuite) and sales/leads in Salesforce. If a product goes out of stock in NetSuite, open Salesforce opportunities need to be updated instantly so reps don’t overpromise. On the flip side, if a large deal closes in Salesforce, NetSuite needs to reflect the inventory commitment right away.
- A B2B consultancy uses Salesforce for sales/customer support and QuickBooks for finance/invoicing. When a sales rep closes a deal in Salesforce, an accurate invoice needs to be generated in QuickBooks. Crucially, Salesforce needs to be updated when payments close so sales teams aren’t kept out of the loop.
- A SaaS company needs to integrate Salesforce with its payment services product, Stripe. If a customer’s payment fails in Stripe, Salesforce must reflect it instantly and notify the relevant account manager to chase up and resolve the issue. If a sales rep updates the customer’s plan in Salesforce, Stripe needs to update subscriptions right away to avoid billing errors.
In these situations, real-time information is non-negotiable. Crucially, each example requires information to travel in both directions. Ultimately, real-time isn’t real-time unless it’s bidirectional. In short, Salesforce needs to be able to both talk and listen, instantly.
If it can’t, there’s a real risk of financial forecasts being out of date and sales teams being out of the loop in front of customers. Nobody wants this. But building reliable real-time connections between Salesforce and third-party systems is easier said than done.
Building a Realtime Salesforce Integration: Where to Start
Historically, achieving true real-time functionality required heavy Apex code or costly middleware. For many, the time and costs involved were simply prohibitive. Now, there are more options available, but the devil remains very much in the details.
If you’re familiar with the Salesforce landscape, there’s a good chance you’ll already know some of the mainstream options: ETL, out-of-the-box connectors, or Flow HTTP Callouts.
These are generally great for moving data in one direction, infrequently. But when it comes to syncing large amounts of real-time data at scale, they struggle to cope. This leads to a range of common issues:
- High resource requirements: Many integrations rely on polling or full-system syncs, which can be incredibly resource-intensive.
- Brittle pipelines: Small updates to Salesforce objects, fields, or the external API can easily break the pipeline, creating hours of troubleshooting.
- Latency: Many tools claim to be real-time, but they actually just poll frequently. This creates lag without solving the resource issue.
- Compliance: Many common products (particularly middleware vendors) store or cache data off-platform, often without you knowing. This makes it impossible to achieve data protection compliance, since you can’t guarantee that data is stored in-jurisdiction.
To avoid these issues, there are several important questions you need to ask when researching or building your Salesforce integrations:
- How quick is it to set up? No company wants to spend two months manually building an integration from scratch. It’s important to prioritize speed and efficiency when building or choosing the right approach.
- Where is data stored? To safeguard compliance, you need to guarantee data sovereignty. The easiest way to do this is to use a Salesforce-native approach that ensures data is kept within the Salesforce ecosystem. This avoids the compliance issues involved with middleware vendors and third-party caches.
- Can data travel both ways? In the vast majority of cases, one-way real-time data traffic is about as helpful as having no real-time pipeline at all. However you build your integration, you need to ensure data can flow both ways so teams don’t work in silos or with outdated information.
- How easy is it to set up? Most organizations will want to avoid building the pipeline from scratch, as the cost and time required are prohibitive. But out-of-the-box tools may lack the flexibility and customizations you need. The best approach is to combine low or no-code functionality with the ability for developers to add custom code via Salesforce Apex. This is the best balance of speed, costs, and flexibility.
- What are the resource implications? If you need genuine real-time functionality, it’s important to avoid relying on batch syncing or polling. These options are resource-intensive and don’t deliver genuine real-time updates. Instead, prioritize options like event-driven syncing. This enables updates to be made as they happen, which eliminates the lag and inefficiency of batch syncing/polling, while still keeping resource usage low.
The 4 Building Blocks of Realtime Integrations
Most Salesforce integrations that claim to be real-time… aren’t. They poll every few minutes, burn API calls, and leave data stale. But there is a better approach.
Achieving this balance all comes down to how the integrations are built and the architecture you’re using to do so. The right choices here can avoid many of the issues we’ve discussed in this piece. Here’s what that looks like:
- Webhooks: Webhooks are event-driven, eliminating the need for full-system syncs or polling. When new information is entered into Salesforce, the webhook can notify the third-party integration and push data into the app. This eliminates middleware and message queues, while keeping resource requirements to a minimum.
- JSON: JSON is compact and has wide interoperability. This enables webhooks to work easily with a wide range of third-party tools, while keeping bandwidth and storage costs low.
- REST API: This enables bidirectional data travel, meaning updates made in (for example) QuickBooks can impact/change information saved in Salesforce. It also means the third-party system can query webhooks and request more details/context. This helps to keep the original webhook compact without sacrificing data completeness or integrity.
- Salesforce Apex: The standard programming language of Salesforce. This means Salesforce developers can easily modify the code to create bespoke functionality or requirements where needed.
Declarative Webhooks is an integration tool that lets admins build robust, bidirectional, and real-time integrations in minutes – with clicks, not code. This is one of the only options on the market that combines all of these elements into a single, integrated, and Salesforce-native product.
Together, these help to give Declarative Webhooks a unique approach to managing real-time Salesforce data:
- Genuine real-time: Declarative Webhooks offers instantaneous, bidirectional updates, with no lag or syncing issues.
- Fast setup with gen AI: Integrations can be assembled in minutes, using clicks, not code. The product also includes generative AI features to make integrations faster to build and errors quicker to find. You can also build Model Context Protocol (MCP) integrations to build communication pipelines with other generative AI services.
- No data/compliance risk: We don’t store third-party data off-platform or in caches. This means you can 100% control what data is sent in and out of Salesforce, eliminating the risk of non-compliance associated with middleware vendors and other insecure integrations.
- Completely customizable: We combine low-code/no-code functionality with a customizable approach built on Salesforce Apex. This enables non-technical teams to build the majority of functionality through drag-and-drop. Then, Salesforce developers can customize the rest easily via Salesforce Apex.
- Resource-efficient: Event-driven updates enable us to have the best possible balance of genuine real-time functionality and a lightweight, efficient setup. This enables us to keep resource usage low and avoid the issues associated with batch polling or syncing.
In short, Declarative Webhooks makes it possible to build Salesforce-native, bidirectional integrations in minutes, using clicks, not code. Say goodbye to brittle pipelines, outdated information, and off-platform data. Whether it’s syncing inventory with NetSuite, generating invoices in QuickBooks, or updating subscriptions in Stripe, Declarative Webhooks ensures Salesforce data stays live and accurate.
Check out Declarative Webhooks on the AppExchange or get in touch with Omnitoria to find out more.
