An Architect’s Guide to Salesforce Integration
Jacqui Park is a Senior Salesforce Solutions Architect at RafterOne with over a decade of experience consulting, building and delivering solutions to customers. She’s a Salesforce-certified specialist in digital transformation, CRM & Enterprise Resource Planning (ERP) consulting, data management and business intelligence. And if that wasn’t enough, she’s also a former professional boxer.
I had the pleasure of working with Jacqui several years ago at Nubik — now Deloitte Digital — a Salesforce partner. Jacqui taught me a lot about Salesforce implementations, best practices, and she’s an expert in the world’s top CRM with a wealth of knowledge most consultants could only dream of.
We spoke recently about the rise of a technology that gives Salesforce engineers and consultants a particular edge when it comes to delivering work to clients. No, not AI although Salesforce does have that covered with the new Agentforce. I’m talking about no-code and low-code tools.
It might just turn out that you don’t need AI to make the best Salesforce integration; you just need no-code.
What is a Salesforce architect?
So before we get too deep, let’s start with the basics: what exactly is a Salesforce architect? We know they’re not designing skyscrapers, though the analogy isn’t far off.
Salesforce architects are the unicorns of the Salesforce development world: consultants with a specialized technical skillset who serve as deeply trusted digital advisors to clients and implementation partners alike. They can advise a business on app purchasing strategy and share reports with stakeholders.
They can work with developers on implementing exactly what the customer requested, and even roll up their sleeves to help deliver it themselves.
Here’s how Jacqui got her start in the world of Salesforce:
I was a systems analyst for a manufacturer in the early 2000s; I owned all the data, which was a super fun job. I learned a lot more about data and business intelligence, ERPs and manufacturing. Then I got headhunted into a Director of Consulting role at a Dynamics 365 shop. From there, I was exposed to Salesforce frequently.
So, I started doing Trailhead, loved it, and got my job first job as a consultant shortly after. Not too long after that I was hired as a pre-sales architect and got some really great experience working in client relationships and account management. That helped me align this new sales skillset with my technical side.
– Jacqui Park, Senior Salesforce Architect
What do we mean by Salesforce integration?
Salesforce integration is a term that can mean quite a few things to different people, depending on their background. However, to help set the stage, think of integration as the connection between two systems. That includes connecting Salesforce organizations to other apps and tools or even other Salesforce organizations to transfer data back and forth.
Integration is typically achieved through a Salesforce connector built by a third party (such as Unito) or built by your organization. A custom Salesforce connector can be built using the Salesforce API. This requires deep technical knowledge, so this article won’t describe how to build your own custom Salesforce connector.
Why is Salesforce integration important?
Today there are more apps and tools available for work than ever before. The global SaaS market size is projected to grow beyond $317 billion USD by the end of 2024. And today, Salesforce is no longer the only CRM or work management tool for marketing and sales teams. It has a range of competitors nipping at its heels, including including HubSpot and Pipedrive.
According to one Salesforce study, 81% of IT leaders claiming that data silos are hindering their digital transformation efforts. 75% of respondents from that same study said the inability to connect data-derived insights into user experiences is a significant challenge.
One solution being explored by savvy IT leaders is integration: either via low-code or no-code solutions.
So, a no-code approach to integration is really interesting since it makes a lot of functional IT work possible for a consultant who might be technical, but doesn’t necessarily have a background in, say, C sharp or Java or even Apex.
– Jacqui Park, Senior Salesforce Architect
Salesforce integration vs automation
I asked Jacqui about the main challenges she observed among Salesforce users trying to automate their work. There are only a handful of tech companies addressing these challenges, virtually all of which revolve around “if this, then that” logic engines (e.g., the Mulesoft‘s and Workato‘s of the world).
Automation users are limited to building out carefully-structured recipes made of triggers and actions. These tools are great for sending dedicated pieces of information in a single direction, but as an organization scales, they become more unwieldy and costly.
Observability and maintenance become constant topics of discussion as teams spend more time adding guardrails to the automation than they get back from it.
These tools are great for sending dedicated pieces of information in a single direction, but as an organization scales, they become more unwieldy and costly. Observability and maintenance becomes an overarching topic of discussion as teams spend more time adding guardrails to the automation than they do benefitting from it.
If there’s no documentation, teams end up inheriting something they don’t understand. A Salesforce Center of Excellence is usually what some of the bigger companies will have. And then within that, there’s sort of the governance piece where everything has to be approved and reviewed, and it’s done in releases.
– Jacqui Park, Senior Salesforce Architect
The perils of automating Salesforce on a whim
There are upsides and downsides to automating routine tasks in Salesforce: once completed, you will have a system that transfers data automatically to reduce manual effort, however the automation tool will only sync data that fits the rigid criteria you define, no outliers accepted. They also aren’t cheap tools to use at scale, and their cost increases as your usage expands to cover more and more edge cases.
Without careful planning, a seemingly “free” automation tool can balloon into a serious budget buster.
While automation has its pros and cons, it’s not the latest technology available for Salesforce teams who want to connect their organization to other tools.
What is a no-code Salesforce integration?
Integration refers to a more streamlined automation process by which a user can establish a connection between two apps with fewer restrictions. It allows users to set parameters for which data points to include or exclude, while the general system is more forgiving in allowing data to sync in bulk. In other words, you can sync everything off the bat, or only specific objects or items, and your “flows” can be edited to be more or less flexible.
No-code generally implies a platform that doesn’t require the user to be an expert in JavaScript, Apex, or code of any kind. Full disclosure, yes Unito is a no-code tool, but I promise to avoid the heavy sales pitch as much as I can.
The key functionality of a no-code platform is the use of a visual interface, often known as a flow. A flow allows you to see the connections between your Salesforce organization and another app or tool from a more conceptual perspective than lines of JavaScript, XML, or JSON. Instead, you would select your preferences and options from drop-down menus that pull data from the source: your Salesforce account.
Are no-code Salesforce solutions secure?
This is where due diligence comes into play. An integration is only as secure as the weakest link — if any of your tools have a security flaw, the entire workflow can be put at risk. So, when you’re looking for a no-code Salesforce integration, check their security credentials, compliance records, and anything else you can find to certify their commitment to your data privacy. On that note, Unito is SOC 2 Type II certified and all our user data is encrypted in transit.
The Cost of Salesforce Integration and options for users
So now that we know a bit more about automation vs integration and where no-code comes into play, we can talk about the big question: cost.
When we talk about cost it doesn’t just refer to the budget. The time and labor involved in setting up your integration is just as important to both your output and how resources are spent.
If your goal is to sync data to or from a Salesforce organization, you can automate, integrate, build a custom connector, or hire a consultant to set it up for you. No-code is becoming such a popular choice, that many automation providers have pivoted to a “low-code” solution as a compromise between their traditionally complex automation tools and the rise of new, simpler no-code integration alternatives.
Many low-code options appear to be the same as no-code on the surface (or in a sales call) but once you get into the product, you’ll find that advanced functionality requires more than a little coding knowledge.
Mulesoft doesn’t come cheap with a starter package beginning at $27k USD annually. So an alternative could be the custom integration option, but then you have to consider the salary of the team building it. At the lower end, entry-level integration developers earned $79k USD in 2024 with the average salary hovering around $50 per hour for more experienced devs.
Meanwhile, a no-code integration solution such as Unito has plans that enable you to achieve just as much at the lowest total cost of ownership. The platform even offers customized integrations for Unito enterprise users withs deeper functionality than any automation tool and it’s much easier to sync at scale than Mulesoft.
So a no-code option like Unito, to me, sounds like it could be a really good fit for businesses that need a really good tool to integrate several systems but don’t have the money for something like a Boomi or a Mulesoft. And if there’s a partnership involved, that’s kind of where it starts.
– Jacqui Park, Senior Salesforce Architect
What does a no-code Salesforce integration look like in practice?
When Jacqui and I worked together, the team would implement Salesforce instances for businesses in the manufacturing sector; often with Service Cloud and Field Service. Typically, these would be HVAC companies, teams with technicians, etc.
We often work with companies who have five or six different tools used to gather information, and then they need to be able to pull that into Salesforce. Often it’s for a work order so a technician can see the same information in real-time. When I look at a Salesforce case, I should be able to see all the work orders, accounts, assets, anything they’ve ever ordered. But that won’t necessarily be in Salesforce. All of those things may be in separate systems.
– Jacqui Park, Senior Salesforce Architect
So the business would need to be able to track inventory, equipment, and vehicles across multiple facilities and regions. Then they’d often want a system in place for dispatching teams using optimal routes while also offering a reasonable schedule for each field team. This isn’t easy to manage manually, but with the help of an integrated Service Cloud module, that’s exactly what we delivered.
From a technical standpoint, most of the information used by those teams needs to be pulled in from multiple sources in order for each team involved to function efficiently. That includes a CRM, such as Salesforce or HubSpot, the ERP, project or task management tools, or software development tools for DevOps use cases.
Maybe they keep all their serial numbers in one system, maybe they keep all their purchase orders and equipment information in another. You want all of that information to come into Salesforce at some point and be visible on the account, the case, and the work order. So that whatever information you need to see, wherever you are in the system, it’s all connected so that you’re not hunting or swivel-sharing into multiple systems.
– Jacqui Park, Senior Salesforce Architect
How do you start building a no-code Salesforce integration?
Whether you’re new to integration or an experienced developer, the typical process is relatively straightforward: start small, test, adjust, and repeat.
Start small, scale over time
Jacqui and I would often work with teams who would ask Salesforce consultants to provide them with everything but the kitchen sink in a single project. That’s fine when you’re working with an implementation partner or a contractor, but no-code tools use subscription models. One plan gives you unlimited access to the tool for as long as you want it.
So set up a test workflow with a limited scope to get comfortable with the environment you’ll be working in.
Test, test and test again
We all want our integrations, apps or other services we purchase to work perfectly the first time. Sometimes that’s possible, sometimes it’s not. The flexibility of a no-code platform means the outcome of your Salesforce integration depends entirely on how you set it up.
Start in a test environment or with a limited scope of work. Then, you can experiment with different configurations and see the results before going live. Doing this with a consultant costs time and money, so we tend to avoid this way of approaching integration/implementation work. But when you’re using an iPaaS tool, you have all the time in the world to get it right.
Always remember: the system will do what you tell it to do, no more, no less.
Adjust and iterate
If you’re like me, and you happen to have read this far, then you’re someone who loves to learn and expand your skill set. I’ve been at Unito for three years and I’m still learning new ways to use the platform. In my case, I realized that a synced field doesn’t always have to be linked to the same field type in your other connected tool.
A label or tag in one Salesforce object doesn’t need to link with a label or tag in a Jira issue, for example. Instead, you could link it to the issue status or assignee if that’s what the information in the original label contains.
In your case, it’s always safe to begin with pre-populated field mappings, but once you’ve seen what a no-code platform can do for your workflow, you can experiment, add new field mappings, remove redundant ones, and configure them on a deeper level. Or you can try adding new flows and connections as you ramp up your skill set.
You have to take baby steps because there are so many systems to consider. Are we pulling the data in? Are we actually bringing it into Salesforce? Is there an easier way to sync it that’s not as expensive as a Mulesoft or a Boomi? Even then, the data in those different systems usually needs to be cleaned up as well. It’s different object types, different formats. There are all these different things you have to think about. But if you could bring it in and make it like accessible in one place where it all syncs up.
– Jacqui Park, Senior Salesforce Architect
Summary
The typical Salesforce integration guide starts with a lot of complex, technical concepts including REST APIs, SOAP APIs, web service callouts, and batch data synchronization. The benefit of a no-code Salesforce integration is that you don’t need to be an expert who can define those terms. Instead, you simply need to know what you want to achieve and experiment with a visual interface until you get there. And since Unito comes with a free trial, you’re more than welcome to experiment with our visual flow builder or jump on a call with us for a free consultation.