Salesforce integration services · ERP and finance · APIs and events · native tooling or middleware · certified partner
Most estates were not designed, they accreted: an interface per project, each solving one problem well and none of them reusable. We map what actually runs, settle the edition and approach questions before anyone writes a connector, and leave something the next integration can build on.
The exposure, first
An out-of-date reporting tool is inconvenient. An out-of-date integration runtime is a component sitting between your CRM, your ERP and your finance system, usually holding credentials to all three, that has not received a security patch since March 2024. That is a different conversation, and it is the one that gets funded.
API access is included by default in Enterprise, Unlimited, Developer and Performance editions. Professional Edition must order the Web Services API product, and the Additional API Calls add-on does not enable API access for Professional. Group and Essentials cannot buy it.
A real share of requirements never needs middleware. Flow HTTP callouts, External Services, Platform Events, Change Data Capture and Salesforce Connect for read-only external data all come with licences you already hold.
Each one solved its problem well and none of them were built to be reused, so the fourth team that needs customer data writes a fourth way to read it. That is not laziness, it is what happens when nobody owns the model.
A catch-all error handler that logs and continues looks tidy and hides everything. The first person to notice is a customer, or a finance team reconciling numbers that do not add up.
Written by someone who left, undocumented, load-bearing. Every estate has two or three, and they are exactly the ones that make a migration estimate uncertain until somebody reads them.
Now that MCP is generally available, the ceiling on what your agents can do is your integration layer. An estate nobody has designed becomes the constraint on the AI programme, quietly.
What we actually build
These reflect how integration architects and platform teams describe the problem rather than a feature list. Most engagements start with the first two, because an estate you have not inventoried is one you cannot safely change.
Every application with its runtime version, deployment target and last release, plus which APIs are genuinely called. The finding is usually that a lot can be retired.
Not alphabetically and not by ease. The applications handling the most sensitive data on the unsupported runtime go first, with the rework budgeted honestly.
System, process and experience layers introduced where they earn their place, so the next team reuses a customer API rather than writing a fourth one.
Real error strategies rather than a catch-all that swallows everything, plus retries, idempotency and dead-letter handling where the receiving system needs it.
API Manager policies, versioning and deprecation, environment strategy, and a catalogue somebody can actually search before building the next thing.
MuleSoft MCP servers and Topic Center scoped so agents reach what they need, with admin control over which tools they may call.
Scope of delivery
From an estate inventory through to run-state operations across Anypoint Platform, Mule 4 runtime, API Manager, Model Context Protocol and MuleSoft for Agentforce, scoped with named owners, a measured baseline, and the unsupported runtime dealt with first.
An integration is a product with an owner, not a task that finished. The estates that stay healthy are the ones where somebody is accountable for each interface after the project that created it has closed.
Applications, runtime versions, deployment targets, last release, real call volumes, and how much of the estate is unsupported. Yours whether or not you engage us.
Sequenced by exposure rather than by ease, with the rework on connectors, error handling and transformation estimated explicitly rather than assumed.
System, process and experience APIs where reuse is genuine, with tests, error handling and observability built in rather than retrofitted.
The joins that carry your business: CRM to ERP, finance, logistics and field tools, with the boundary of which system owns which fact agreed before build. See Salesforce consulting.
Monitoring, alerting and runbooks so a broken interface reaches a human before it reaches a customer, plus the consumption data you need at renewal.
A named team for the run-state backlog, runtime upgrades and new interfaces, optionally as managed services.
MuleSoft MCP servers, API Catalog sync and Topic Center, scoped so agents reach what they need and nothing else. See Agentforce services.
The work
Integration briefs arrive named after systems, but the work is nearly always one of these shapes. Recognising which shape you have is what determines whether the answer is a new interface or a change to something that already exists.
SynconAI integration spine for scoping workshops. The first step is the one most often skipped, and the one that causes the arguments eighteen months later.
Accounts, orders, invoices and stock moving between Salesforce and SAP, NetSuite, Dynamics or an in-house system. The hard part is never the connector, it is agreeing which side owns the customer record and what happens when they disagree.
Quote, order, fulfilment, invoice and payment across three or four systems. Every failure here is visible in the ledger, so idempotency and replay matter more than anywhere else in the estate.
Pulling a single view from systems that each hold a different partial truth. Usually a case for an experience API over several system APIs rather than another nightly copy into another database.
Platform Events, Change Data Capture and a message broker, so a change in one system reaches the others without a nightly batch and a four-hour window where the two disagree.
Logistics, payments, identity, credit checks. Rate limits, retries and graceful degradation matter, because the failure mode you cannot control is somebody else's outage during your busiest hour.
The newest shape, and the one that changes the design brief. An MCP server over an existing API, scoped so an agent can read what it needs and write only what you have explicitly allowed.
Reference architecture
The three-layer model works, and it works because each layer has a job: system APIs hide the source, process APIs hold the business logic, experience APIs shape the response for one consumer. Where it goes wrong is applying all three to an estate with six interfaces, which produces ceremony rather than reuse. We introduce layers where a second consumer genuinely exists or is genuinely coming, and we say so plainly when a direct system API is the right answer. Every pattern depends on your edition, runtime and deployment model; your account team and the Salesforce release notes remain authoritative.
SynconAI reference topology for workshops. Read upwards: nothing above is worth building until the layer below it has an owner and a contract.
SynconAI integration stack
Governed AI
An explicit list of what an agent may reach, and what it may change
This is the part of an agent programme that belongs to the integration team rather than to whoever owns the AI budget. MuleSoft MCP servers expose a system to an agent, API Catalog syncs them into Agentforce, and admins control which tools an agent may call. We scope each server as a deliberate list rather than a convenient one: what may be read, what may be written, what requires a named human, and what is simply not exposed. Then we make the calls auditable, because "an agent did it" is not an acceptable answer to a finance question. Details on our Agentforce services page.
An MCP server over an existing API rather than a new back door, with the read and write surface listed explicitly so somebody can review it in an afternoon.
Topic Center builds Agentforce topics from your API design or the APIs you already run, which keeps agent capability tied to something governed rather than invented alongside it.
Every agent-initiated call attributable, so when somebody asks why a record changed the answer is a log entry rather than a shrug.
Governance & operating model
Every sprawling estate was tidy once. Each project ships an interface, closes, and leaves something load-bearing with no owner. Two years on nobody can say if it is still needed. The fix is a name against each interface, not more architecture.
Recorded in the catalogue, reviewed when people move on. It is the single highest return governance artefact and it costs a column in a spreadsheet.
A published policy for breaking changes and a route to switching an API off, because an estate that can only grow eventually stops being changeable.
Authentication, rate limiting and logging applied as a baseline rather than remembered per API, so a rushed release cannot quietly ship without them.
Properties encrypted, secrets managed rather than sitting in a config file, and a rotation process that somebody has actually run at least once.
A standing cadence for runtime patches and version upgrades, because the whole reason estates rot is that tidying up was always next quarter.
A periodic read of what agents can currently reach and change, because that surface grows quietly as topics are added and nobody re-reads the whole list.
Pair the work with a governed data programme when identity and lineage need attention before agents scale. See Data 360 services.
Plan a governance workshopWho we work with
The same piece of work gets funded or deferred depending on who is asking and what they call it. A runtime migration is unglamorous; the same migration described as removing unpatched middleware from between your core systems is a different conversation. Tap the group closest to you to pre-scope the conversation form.
Partnership criteria
Integration specialists sell integration, so the answer is always more of it. We also run the Salesforce practice, which means native tooling is genuinely on the table when it is the right answer, and we lose nothing by saying so. Learn more about our Salesforce consulting partner approach.
Applications, runtimes, real call volumes and unread flows. You keep the document whether or not you engage us, and it usually shows fewer critical interfaces than anyone expected.
The applications on the unsupported runtime handling the most sensitive data go first. Progress that does not reduce risk is motion, and it is easy to mistake for delivery.
Flow callouts, External Services, Platform Events and Salesforce Connect come with licences you already own. When they do the job we say so, which costs us the larger engagement.
Real error strategies rather than a catch-all, alerting that goes somewhere, and runbooks for the failures you already know about. The measure is whether you find out before your customer.
Hubs in Delaware, Sydney and Hyderabad, a named team on your business hours, and travel onsite for discovery, cutovers and executive sessions.
The same architects for new interfaces, runtime currency and the incidents, so nobody has to rediscover why a flow was written the way it was.
Delivery method
Six beats we repeat on every engagement, with transparent gates and no surprise scope. The unusual one is second: triage happens before design, because an estate with an unsupported runtime has a security problem that should not wait behind an architecture exercise. Same method as our broader Salesforce consulting practice.
Every application with its runtime version, deployment target and last release, which APIs are genuinely called and by whom, and the undocumented flows read rather than left as unknowns. You keep the write-up either way.
Unsupported runtime and unmanaged APIs ranked by exposure rather than by ease, so the first thing delivered is the thing that reduces risk. Retirement candidates identified here too, because the cheapest migration is the one you do not do.
API-led layers introduced where a second consumer genuinely exists, with the system-of-record boundary agreed before anyone writes a connector, and the specification published so other teams can build against it.
Interfaces with real error strategies, retries, idempotency where money is involved, MUnit tests as a release gate, and monitoring configured before go-live rather than after the first incident.
Policies applied by default, versioning and deprecation published, a catalogue people search before building, and a named owner against every interface so the estate does not become nobody's again.
MCP servers and Agentforce topics once the APIs underneath are worth exposing, plus runtime currency on a cadence so this does not recur. Optionally continue with managed services or ongoing Salesforce administration.
Client reviews
Verbatim reviews from SynconAI Salesforce and Agentforce engagements across the United States, Australia and globally. Anonymised clients are labelled by sector.
Salesforce Select Partner16+ architect certificationsDelivery across USA, Sydney & India
Simply Outstanding
“SynconAI Consulting are Simply the Best in the Business When it comes to Salesforce implementation and AI-powered solutions, SynconAI are in a league of their own. Their expertise, dedication, and ability to deliver results that truly move the needle sets them apart from every other consulting partner we've worked with. What they achieved with our Sales Cloud, Service Cloud, and custom Agentforce agent has completely transformed how we operate streamlining our pipelines and our customer service, and automating tasks that used to consume hours of our team's time. They don't just implement technology they transform businesses. If you want the best, you work with their team.”
“I had a very urgent deadline for our project reporting to be delivered and needed to build the module, dashboard and output reports in Salesforce. SynconAI were very responsive - they met with me online, responded to my emails quickly and took calls - whatever was needed to progress the work quickly. We are thrilled with the outcome and will continue to work with SynconAI in the future to continue to build our Salesforce capability and platform.”
“The team at SynconAI were fantastic, and promptly delivered on each project. They were able to guide us through every stage and made sure we were satisfied with the outcomes on multiple scopes of work.”
“They have been great and helping us transform out business by bringing what I conceptualize to life. Great at translating process/workflow needs into a solution. Been a pleasure work with and they're a critical part of our team and will be instrumental into bringing about my vision.”
“Working with SynconAI was a seamless and highly professional experience from start to finish. They took the time to deeply understand our business processes before designing and implementing a Salesforce solution tailored specifically to our operational needs. The team demonstrated strong technical expertise across Salesforce configuration, automation, integrations, reporting, and user experience design.”
Frequently asked questions
Straight answers on what your edition allows, whether native Salesforce tooling is enough, when middleware earns its cost, and who owns an interface after go-live.
Often natively. Where Salesforce is one end of the integration and the requirement is modest, Flow with HTTP callouts, External Services, Platform Events or Salesforce Connect for read-only external data will do it on licences you already hold. Middleware earns its cost when you have many systems, real governance obligations, reuse worth enforcing, or an agent programme that needs a controlled way to reach everything. We map the requirement against both before recommending either.
It can be, and it is the most common thing a project discovers too late. API access is included by default in Enterprise, Unlimited, Developer and Performance. Professional Edition has to order the Web Services API product separately, and buying the Additional API Calls add-on does not enable API access for Professional. Group and Essentials cannot buy it at all. If anything on your roadmap involves connecting a system, settle this before you sign, not in month nine.
This page is the decision and the delivery: what has to connect, which approach the requirement justifies, and who runs it afterwards. The MuleSoft page goes deep on one platform — Anypoint, runtimes, Mule 3 end of life and API-led layers — and is the right read once you have decided MuleSoft is the answer, or if you already own it.
Salesforce supports both, so the protocol is rarely the hard part. REST is the default for new work. SOAP still matters when the system at the other end only speaks it, which in finance and older ERP estates is common. Volume work goes to Bulk API 2.0, and anything that should react to a change rather than poll for it goes to Change Data Capture or Platform Events.
Rarely the connector. Projects miss on assumptions: that a system could take the load, that the data was as clean as the schema suggested, that a flow nobody had read did what its name implied. Each of those moves an estimate by weeks, and finding them in testing is what turns a fixed price into an argument. We surface them in the mapping stage instead.
Someone should, in writing. The common failure two years on is not a broken connector but an interface nobody can say is still needed, so nothing is ever retired and everything is slightly risky to change. We hand over a named owner per interface, a rule for what happens when a source system changes, and monitoring that tells you before a customer does.
Salesforce, MuleSoft, Anypoint Platform and Agentforce are trademarks of Salesforce, Inc. SynconAI is an independent certified Salesforce consulting partner and is not created by, affiliated with, or endorsed by Salesforce, Inc. Edition entitlements, API allocations and packaging are set by Salesforce; the Salesforce release notes and your account team remain authoritative. Screenshots are reproduced for illustrative purposes.
Free architect conversation
60 seconds to brief us. A certified architect replies within one business day.
Sales Cloud
Service Cloud
Field Service
Experience Cloud
Marketing Cloud Next
Revenue Cloud AdvancedSalesforce CPQ
Data 360
Financial Services Cloud
Nonprofit Cloud
Health Cloud
CRM Analytics & Einstein
Agentforce