MuleSoft integration services · Anypoint Platform · Mule 4 migration · MCP for Agentforce · certified partner
Most MuleSoft estates were not designed, they accreted: an interface per project, each solving one problem well and none of them reusable. We inventory what you actually run, deal with the unsupported runtime first because that is exposure rather than debt, and then make the estate 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.
MuleSoft ended extended support for the Mule 3 runtime on 20 March 2024. No bug fixes, no security patches, no new features. If Mule 3 is still running in your production estate, it is unpatched middleware sitting between your systems, and that is a security position rather than a technical debt position.
The Mule Migration Assistant helps, and it is not a one-click upgrade. It produces migration reports and a partial conversion; connectors, error handling and DataWeave 1 to 2 all need real work. Treat it as a head start on a rebuild rather than as the rebuild itself.
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, with the Migration Assistant used as a head start and the connector, error-handling and DataWeave rework estimated explicitly.
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 MuleSoft 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 Anypoint MQ, 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 MuleSoft 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 Mule 3 became a problem is that upgrading 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.
Mule 4 applications 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 about the Mule 3 end of support date, what the Migration Assistant does and does not do, MCP and Agentforce, licensing, and whether you need this platform at all.
More urgent than most technical debt, because it is not technical debt. MuleSoft ended extended support for Mule 3 on 20 March 2024: no bug fixes, no security patches, no new features. That means any vulnerability discovered since then stays open in a component sitting between your core systems, usually holding credentials to all of them. We would treat that as a security item with a date rather than a modernisation project competing for next year’s budget, and we would sequence the migration by exposure rather than by which application is easiest.
It helps, and it is not a one-click upgrade. The Migration Assistant produces migration reports and a partial conversion, which is a genuine head start. What it cannot do for you is the connector changes, the error-handling model, and DataWeave 1 to 2, which is where the actual effort sits. Any plan that budgets the assistant as the migration will discover the rest late, usually during testing. We estimate the rework explicitly and tell you which applications are close to mechanical and which are effectively rebuilds.
Model Context Protocol is how an AI agent reaches a system it does not natively know about, and support for it is now generally available across Anypoint Platform. API Catalog syncs MuleSoft MCP servers into Agentforce, with admins controlling which tools agents may call. The reason it matters strategically is that it makes your integration layer the thing that determines what your agents can do. An agent is only as capable as the systems it can reach, and only as safe as the boundary you put around them, and both of those are now integration decisions.
We can measure it, which is usually the missing piece. Analyst and partner commentary consistently reports organisations committing to more capacity than production actually consumes and describes the metrics as hard to forecast; we would rather present that as the commentary it is than repeat it as fact. What we do is instrument what your estate genuinely uses, identify applications that are over-provisioned or no longer called at all, and give you that evidence before a renewal rather than after. We are a consulting partner, not a reseller, so nothing in that analysis changes what we earn.
Sometimes simpler would do, and we will say so. If you have a handful of point-to-point interfaces and no plans to grow them, a platform of this weight is hard to justify on its own. MuleSoft earns its place when you have many systems, real governance requirements, reuse worth enforcing, or an agent programme that needs a controlled way to reach everything. If you already own it, the question is different: it is whether the estate is designed or accreted, and that we can answer from your own catalogue.
Yes, and it starts with an inventory rather than a rebuild proposal. Applications and their runtime versions, what is deployed where, which APIs are actually called and by whom, what error handling exists, and which flows nobody will touch because the author left. You get that as a document whether or not you continue with us. In most estates it shows a smaller number of genuinely critical interfaces than expected, surrounded by a lot that could be retired.
MuleSoft, Anypoint Platform, Salesforce 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. Runtime support dates, packaging and entitlements are set by Salesforce; the MuleSoft 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