SmartConnect’s Salesforce connector is one of the platform’s oldest integrations (it was also the first non-Microsoft connector ever added). Over the years, it’s gone through plenty of changes, but this update is one of the biggest revamps yet. These changes are designed to make the connector faster to build on, easier to maintain, and better aligned with modern best practices.
We covered the Salesforce connector this week on New SmartConnect Office Hours. If you’d like to watch a video explaining the Salesforce Connector update, see here:
Moving to the REST API
The Salesforce connector is now built on a REST API, mirroring a similar shift made recently for the Dataverse/CRM connector. The goal of this was to preserve as much existing functionality as possible while modernizing the underlying technology. SOQL queries and bulk and real-time changes still work, but what’s different is how those capabilities are delivered on the backend.
That modernization meant retiring a couple of things:
- Basic token authentication is gone. Salesforce is phasing this out and will eventually remove it as an option entirely, so the connector has moved to OAuth-only authentication.
- Custom Apex code is no longer required for Change and Real-Time data sources. For anyone who’s spent time debugging Apex triggers, this change will give a simpler experience. It will be easier to set up, easier to move between sandbox and production, and generally quicker to build on.
Sandbox and Production Connectors
One major change is that Sandbox and Production are now split into two separate connectors, linking through a parent-child relationship instead of being tabs within a single connector. You choose whether a given connector is Production or Sandbox via dropdown, and each gets its own connector record.
From a licensing standpoint, the Sandbox connector is still free. However, adding a Sandbox connector requires linking it to a valid Production connector. This allows Change and Real-Time data sources to move properly between environments.
New Authorization: OAuth and JWT
The Salesforce connector now supports a new OAuth process built around JSON web tokens (JWT), to fit with the authentication method Salesforce recommends. Setting it up still starts the way it always has. You set up the apps in Salesforce as usual, but now there’s an option to enable JWT Bearer Flow.
Here’s how that process works:
1. Generate the ticket inside SmartConnect and download it. You choose how long the certificate should remain valid. It can be replaced or regenerated at any time, and pointed to a new app whenever needed.
2. Upload the certificate into the Salesforce app.
3. Validate the connection
Data Sources: SOQL, S-Objects, and the Metadata Browser
On the data source side, there are a few things worth noting.
- SOQL queries still work exactly as they did. Anything you have built will continue to function.
- S-Objects are now supported as a data source option, meaning views already created in Salesforce can be leveraged directly. This is a shortcut for Salesforce power users who prefer working with objects or views already defined elsewhere, rather than writing SOQL from scratch.
- The Metadata Browser is also available for the connector, letting you build and test SOQL queries or do a quick data lookup in the Salesforce environment before copying the query into your integration data source.
Change Data Sources: Data Filters instead of Apex Triggers
We are no longer using Apex triggers, so Change Data Sources now work off an incremental date filter instead. SmartConnect tracks the last processed date/time (which can be manually edited in Edit mode), and after each integration run, that marker moves forward automatically.
This change allows us to minimize custom code requirements, but with that comes one trade off: Change Data Sources no longer support field-level triggering. If you need to trigger off a field change, you’ll need to use the Real-Time option instead.
Real-Time and the Callback Behavior
Real-Time data sources support field-level triggering. The callback can behave in one of two ways depending on how complex the query is.
1. If the record is simple and contains everything needed directly (it contains the ID and the relevant fields are on the base object), it can be processed without an extra call.
2. If you need something more complex, a SOQL query is run to pull the additional data, which requires an extra API call.
For most CRM scenarios, the base object alone typically isn’t enough detail, so the SOQL lookup path is common.
Building Integrations: Lookups, Execution Mode, and Caching
Inside the integration itself, the core experience stays familiar to the current one. You can still create, update, and delete records, and field mapping and additional columns work the same as before. However, a few new capabilities were added to lookups.
Salesforce Lookup and SOQL Lookup
Salesforce Lookup lets you look up data based on any S-object. For example, returning an account number or name, filtered by a chosen operator and field.
SOQL Lookup is new and lets you write a SOQL query directly and map in variable to filter it. This gives more flexibility to run complex queries as part of a lookup, which wasn’t possible before.
Execution Mode
This setting is being rolled out across lookups, and controls where a lookup runs in the process flow.
- Standard: runs in the order the additional columns are listed, same as before.
- Late Bound: runs after everything else, including all additional columns, as the last step before the request is sent to Salesforce. This is useful for calculations, nesting other additional columns into the lookup, or giving data inserted a step before a little extra time to land before the lookup runs.
- Include in Script: runs at the very beginning of line processing, which is useful when the result feeds into a calculation or similar early-stage logic.
Cache Level
Caching is especially valuable for Salesforce because of its low API limits. There are three levels:
1. Data Row (default): This is the least efficient since it looks up the value for every single row, every time.
2. Document (key fields): This caches based on a specific document or row, so a value like a location code is only looked up once even if it applies to every item in an order.
3. Integration Run: This is the most efficient option and is best suited to data that rarely changes, like an owner. The lookup happens once at the start of the run and is reused from there.
What Stays the Same?
From an end-user perspective (mapping, flow, and the overall building experience), everything should feel familiar. Error messages are the same ones seen with the previous version, and mappings still work the same way with separate create, update, and delete nodes. The goal throughout has been to keep as much parity as possible while modernizing what’s underneath.
Sign up for New SmartConnect Office Hours
The updates within New SmartConnect are here to make it more efficient to build and easier to maintain integrations. If you haven’t signed up for New SmartConnect Office Hours and want to learn more about some of the other updates included, it’s not too late.
Upcoming New SmartConnect Office Hours include:
- October 1: Using New SmartConnect with NetSuite
- November 5: Using New SmartConnect with Dynamics GP
- November 12: Using New SmartConnect with Shopify
- November 19: Using New SmartConnect with Dynamics NAV