Salesforce Service Oriented Architecture
Salesforce Service Oriented Architecture (SOA) is an architectural style where business logic is packaged as discrete, loosely coupled services that other systems call over the network.
Definition
Salesforce Service Oriented Architecture (SOA) is an architectural style where business logic is packaged as discrete, loosely coupled services that other systems call over the network. On the Salesforce platform, those services are usually Apex methods exposed through SOAP or REST, or integrations built so that Salesforce and external systems talk through well-defined contracts instead of direct, tangled dependencies.
The idea is to treat each capability as a reusable service with a stable interface. A client calls the service without knowing how it works inside. Salesforce supports this with the webservice keyword for SOAP, the @RestResource annotation for REST, generated WSDL files, and callout classes that consume outside services. SOA is a design approach, not a single feature you switch on.
How SOA Takes Shape on the Salesforce Platform
What "service oriented" actually means here
Service oriented architecture breaks an application into separate services, each one responsible for a single business capability. A service has a published contract, runs independently, and can be called by many different clients. The opposite is a monolith, where everything is wired together and one change ripples everywhere. On Salesforce, a service might validate a credit application, fetch pricing from an ERP, or post an order to a fulfillment system. The caller does not need to know the internal logic. It sends a request that matches the contract and gets a response back. That separation is what people mean by loose coupling. This matters because Salesforce rarely lives alone. A typical org connects to billing, finance, marketing, and data warehouses. If every connection is hand-built and point to point, the integration layer becomes fragile. SOA thinking pushes you to define clean service boundaries instead. You expose Salesforce capabilities as services for others to consume, and you consume external capabilities as services through callouts. The result is a system where each piece can change behind its interface without breaking its neighbors.
Exposing Apex as a SOAP web service
The classic way Salesforce supports SOA is the webservice keyword in Apex. You declare a class as global, then mark individual methods with the webservice keyword. Salesforce automatically generates a WSDL for that class. An external application imports the WSDL and can then call your Apex method as a standard SOAP operation. There are firm rules. You cannot put the webservice keyword on a class itself, only on top-level outer class methods and variables, plus member variables of an inner class. You also cannot use it to define an interface or an interface's members. Methods must be defined as static. The generated WSDL describes the request and response types, so the calling system knows exactly what to send. This pattern is useful when an outside system needs to trigger custom Salesforce logic, not just read or write records. The standard SOAP API and the enterprise or partner WSDL already cover generic data operations. Custom web service methods extend that with your own business rules. The trade-off is that SOAP carries more overhead than REST, so many teams now reach for Apex REST first.
Exposing Apex as a REST web service
Apex REST is the more modern half of Salesforce SOA. You annotate a global class with @RestResource and give it a URL mapping. Inside, methods carry annotations like @HttpGet, @HttpPost, @HttpPut, @HttpPatch, and @HttpDelete. Each one maps an HTTP verb to a piece of Apex logic, so an external client calls a clean URL and gets JSON or XML back. REST services tend to be lighter and easier to consume than SOAP. Mobile apps, single-page front ends, and partner systems can hit an Apex REST endpoint without generating stub code from a WSDL. You still get the same benefit: a published contract that hides the internal implementation behind a stable interface. Both SOAP and REST custom services run under the calling user's permissions and count against platform limits. Authentication is handled through the standard Salesforce session or OAuth from a connected app. Because the service is just Apex, you can reuse the same logic that triggers, batch jobs, and flows already call. That reuse is the heart of the SOA promise: write the capability once, then surface it to many consumers through a thin service layer.
Consuming external services with callouts
SOA goes both directions. As well as exposing Salesforce logic, you often need to call services that live outside the platform. Apex does this with callouts. You can import an external WSDL using WSDL2Apex, which generates stub classes that build the SOAP XML, send the request, and parse the response into Apex objects for you. For RESTful endpoints, the Http, HttpRequest, and HttpResponse classes let you issue GET, POST, PUT, and DELETE calls directly. There are guardrails to respect. A single transaction can make up to 100 callouts, and the request body has a size ceiling, so large payloads need to be chunked or streamed. Endpoints must be registered in Remote Site Settings, or better, accessed through a Named Credential that stores the URL and handles authentication for you. Named Credentials matter for SOA hygiene. They keep secrets and endpoints out of your code, so the same service class works across sandboxes and production without edits. This is how a Salesforce service layer stays loosely coupled to the systems it talks to, instead of hardcoding URLs and passwords that break the moment an environment changes.
Integration patterns that put SOA to work
Salesforce publishes a set of named integration patterns that are really SOA applied to common scenarios. Remote Process Invocation covers calling out to a remote system, split into Request and Reply when Salesforce waits for an answer, and Fire and Forget when it hands work off without blocking. Remote Call-In covers an external system invoking Salesforce, which is exactly what your custom SOAP or REST services enable. Other patterns round out the picture. Batch Data Synchronization moves large data sets on a schedule. UI Update Based on Data Changes pushes notifications to the interface when records change. Data Virtualization lets Salesforce read external data live without copying it in. Each pattern is a service interaction with its own contract and timing. The patterns also flag design concerns that decide whether an SOA integration is reliable. Idempotency is a big one: a service should be safe to call more than once, so a retried request does not create duplicate orders. Outbound messaging, for example, expects acknowledgment within 24 hours, extendable to seven days, before a message expires. Choosing the right pattern up front saves you from rebuilding the integration later.
Where MuleSoft and API-led connectivity fit
For larger landscapes, raw Apex callouts stop scaling well. That is where MuleSoft enters, and its API-led connectivity model is SOA expressed as a layered set of APIs. You build System APIs that open up data in each back-end, Process APIs that combine that data into business logic, and Experience APIs that shape it for a specific channel like a mobile app or a portal. This layering keeps services reusable. A System API for an ERP gets written once, then many Process APIs reuse it. Salesforce becomes one consumer and one provider among many, calling these APIs through Named Credentials and External Services, or being called by them. The integration logic lives in a dedicated layer instead of being scattered across triggers and batch classes. The payoff over time is maintainability. When the ERP changes, you update one System API and the layers above keep working. When a new channel needs data, you add an Experience API without touching the systems underneath. That is the same loose coupling Apex web services give you inside a single org, now applied across the whole enterprise. SOA is the principle; MuleSoft is one mature way to operate it at scale.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Salesforce Service Oriented Architecture.
Hands-on resources to go deeper on Salesforce Service Oriented Architecture.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Salesforce SOA?
Q2. What principle is central to SOA?
Q3. How does MuleSoft relate?
Discussion
Loading discussion…