Salesforce CRM reference architecture
How Sales Cloud, Service Cloud, Experience Cloud, the Salesforce Platform, identity and integrations fit together in one CRM estate, with failure handling and a checklist.
Most Salesforce CRM programmes start with one cloud and grow into several: Sales Cloud for pipeline, Service Cloud for cases, Experience Cloud for customer or partner portals, and a growing list of integrations with ERP, billing, marketing and data platforms. Without a shared picture, each addition brings its own users, credentials and sync jobs, and the org becomes hard to change safely. This page sets out a reference architecture for a Salesforce CRM estate: what each component is responsible for, how data moves, where the trust boundaries sit and what to monitor.
This is a reference design, not a description of a client system. We validate the APIs, editions, licences and permissions for each implementation. GeekMidst can design and implement it as part of Salesforce architecture consulting.
Business context
A CRM architecture serves three groups at once. Sellers need accurate accounts, opportunities and forecasts. Service teams need cases and knowledge with the full customer history. Customers and partners need self-service that shows them only their own records. One data model serves all three, so decisions about objects, sharing and integration affect everyone.
Product names have moved. Salesforce renamed its apps "Agentforce Sales" and "Agentforce Service" in October 2025, and its product pages now use Sales Cloud and Service Cloud again. Portals are documented as Experience Cloud (formerly Community Cloud). Salesforce introduced the Core, Advanced and Max editions on 3 September 2026, so check what your edition includes before designing around a feature. Our Salesforce product names guide covers the changes.
Salesforce CRM reference architecture
Reference architecture: a reusable pattern, not a live client integration
Select a component to see what it is responsible for and how data moves to and from it.
Components and data flows (text version)
| Component | Type | Responsibility |
|---|---|---|
| Sales and service usersemployees | People | Sellers, service agents, managers and admins who work inside Salesforce every day. |
| Customers and partnersexternal users | People | People who use self-service portals to raise cases, check orders or manage deals. |
| Identity providerSSO and MFA | Identity, policy and governance | Your corporate identity provider owns staff authentication, MFA and joiner-mover-leaver processes. |
| Customer identityportal sign-in | Identity, policy and governance | Handles registration and sign-in for external portal users, separate from staff identity. |
| Sales Cloudpipeline and forecasting | Salesforce product | System of record for leads, opportunities and Pipeline Forecasting. Shares accounts and contacts with service. |
| Service Cloudcases and knowledge | Salesforce product | System of record for cases, entitlements and knowledge. Reads the same accounts and contacts as Sales Cloud. |
| Experience Cloudportals on LWR sites | Salesforce product | Customer and partner portals built in Experience Builder. Shows records only as the sharing model allows. |
| Salesforce PlatformFlow, Apex, LWC | Salesforce product | Runs automation and custom UI. Record-triggered Flow for most logic, Apex for complex or high-volume work. |
| Data model and sharingobjects, roles, sharing rules | Salesforce product | Objects, record types, field-level security and sharing. The longest-lived design decision in the org. |
| External Client AppsOAuth for integrations | Identity, policy and governance | OAuth configuration for systems that call Salesforce. Replaces connected apps, whose support ends in Summer '27. |
| Shieldif licensed | Identity, policy and governance | Platform Encryption, Event Monitoring, Field Audit Trail and Data Detect. Licensed separately. |
| Platform Events and CDCPub/Sub API | Integration layer | Publishes record changes and business events. High-volume events are retained for 72 hours for replay. |
| Integration layermiddleware or iPaaS | Integration layer | Subscribes to events, maps payloads, retries failures and calls other systems. MuleSoft is one option. |
| Data 360if used | Data and analytics | Ingests CRM objects through its CRM connectors for unified profiles, segments and AI grounding. |
| Marketing Cloud Engagementif used | Engagement platform | Receives CRM contacts and leads through Marketing Cloud Connect and writes tracking back. |
| ERP and billingsystem of record for finance | External or custom system | Owns orders, invoices and payments. Exchanges data with CRM only through the integration layer. |
| Other business appssupport, telephony, HR | External or custom system | Other systems that need CRM data or update it, each with its own API and limits. |
Data flows
- Sales and service users → Identity provider: staff sign-in. Single sign-on through the identity provider. If it is unavailable, admins keep a break-glass login that is tested and monitored.
- Customers and partners → Customer identity: portal sign-in. Registration and login for external users. Failed logins are rate limited and logged.
- Identity provider → Sales Cloud: authenticated session. SAML or OpenID Connect session. Access within Salesforce is then set by profiles and permission sets.
- Identity provider → Service Cloud: authenticated session. The same SSO session gives access to Service Cloud apps the user is licensed for.
- Customer identity → Experience Cloud: external user session. External users get a portal session limited by their licence and the external sharing model.
- Sales Cloud → Salesforce Platform: record changes. Record-triggered Flows and Apex run on saves. Errors roll back the transaction and are emailed to the automation owner.
- Service Cloud → Salesforce Platform: case automation. Assignment, escalation and notifications run as Flow or Apex on case changes.
- Experience Cloud → Data model and sharing: shared records. Portal users read and write records only through the external sharing model and guest user rules.
- Salesforce Platform → Platform Events and CDC: change events. Change Data Capture or Platform Events publish changes after commit. Subscribers that fall behind replay from the retention window.
- Platform Events and CDC → Integration layer: Pub/Sub API stream. Middleware subscribes over the Pub/Sub API (gRPC). It stores the last replay ID so it can resume after an outage.
- Integration layer → External Client Apps: inbound API calls. Middleware authenticates through an External Client App and writes through REST or Bulk APIs as a least-privilege integration user.
- Data model and sharing → Data 360: CRM connector. Data 360 CRM connectors ingest selected objects on a schedule. Failed refreshes show in the data stream status.
- Data model and sharing → Marketing Cloud Engagement: MC Connect sync. Synchronized data sources poll chosen objects and fields. Every synced contact or lead counts as a contact in Marketing Cloud.
- Integration layer → ERP and billing: orders and invoices. Mapped, idempotent calls with retries. Failures go to an error queue with the source record ID.
- Integration layer → Other business apps: service updates. The same pattern for other systems: mapping, retries and an error queue owned by a named person.
- Marketing Cloud Engagement → Sales Cloud: tracking write-back. Marketing Cloud Connect writes email tracking back to CRM records for sellers and service agents.
Component responsibilities
| Component | Responsible for | Design note |
|---|---|---|
| Sales Cloud | Leads, accounts, opportunities, Pipeline Forecasting | Check which AI features your edition includes |
| Service Cloud | Cases, entitlements, knowledge, contact centre | Knowledge Blocks and AI-drafted articles need a Knowledge add-on licence |
| Experience Cloud | Customer and partner portals | Guest and external users need their own sharing review |
| Salesforce Platform | Flow, Apex and Lightning Web Components | One automation standard per object |
| Data model and sharing | Objects, record types, roles, sharing rules | Agree it before building screens |
| Shield (if licensed) | Encryption, Event Monitoring, Field Audit Trail, Data Detect | Part of the Salesforce Guardian add-on portfolio |
| External Client Apps | OAuth for inbound integrations | Replace connected apps before Summer '27 |
| Platform Events and CDC | Publishing changes for subscribers | Replay window is limited |
| Integration layer | Mapping, retries, error queue, monitoring | MuleSoft or another middleware |
Data flow, step by step
- People sign in. Employees authenticate through your identity provider with single sign-on and MFA. Portal users sign in to Experience Cloud through customer identity.
- Work happens in the apps. Sellers update opportunities, agents work cases, and customers raise cases in the portal. All three read and write the same accounts and contacts.
- Automation runs on the platform. Record-triggered Flow handles most logic; Apex handles complex or high-volume work. See when to use Apex instead of Flow.
- Changes are published. Change Data Capture and Platform Events publish changes after commit. External subscribers use the Pub/Sub API (gRPC, HTTP/2, Avro).
- The integration layer moves data. Middleware maps payloads and calls ERP or other APIs, and writes inbound updates back through REST or Bulk APIs.
- Data and marketing platforms consume CRM data. Data 360 ingests CRM objects through its connectors, and Marketing Cloud Engagement syncs through Marketing Cloud Connect.
Trust boundaries and authentication
There are three boundaries. The org boundary holds your data, users and metadata; sharing, field-level security and permission sets control access inside it. The identity boundary sits with your identity provider, which should own staff authentication. The integration boundary is wherever another system calls Salesforce or Salesforce calls out.
Plan around the authentication changes Salesforce has announced:
- Connected apps support ends in Summer '27; use External Client Apps for new integrations.
- Refresh tokens expire after 30 days of inactivity from 4 November 2026 in production.
- The OAuth username-password, user-agent and hybrid user-agent flows retire on 20 February 2027, and the device flow is restricted from 30 November 2026.
Keep outbound credentials in Named Credentials and External Credentials, never in code; see named credentials explained. Verify these dates in Salesforce Help before planning a cut-over.
Failure scenarios and how to handle them
| Failure | Effect | How to handle it |
|---|---|---|
| Integration token expires or an OAuth flow retires | Sync stops quietly | Move to External Client Apps; alert on authentication errors |
| Subscriber offline longer than event retention | Missed changes | Replay within the 72-hour window, then run a reconciliation job |
| Record-lock errors during bulk loads | Partial updates | Group by parent record, retry with back-off, log failed IDs |
| Two automations update the same field | Inconsistent data | One automation owner per object |
| Portal sharing too broad | External users see other records | Review external sharing; run the Guest User Sharing Rule Access Report |
| Downstream API slow or down | Callouts time out | Make callouts asynchronous; queue and retry in middleware |
Operational monitoring
- Integration health: failed API calls, authentication errors and queue depth, with alerts to a named owner.
- Automation health: Flow and Apex error emails routed to a monitored inbox, and a weekly review of failures.
- Security: Event Monitoring (with Shield) for login and API activity; Setup Audit Trail for configuration changes.
- Limits: API consumption against your org's allocation. Check current limits in Salesforce documentation rather than assuming figures.
- Releases: test each release in a sandbox preview; our release testing checklist helps.
Alternative approaches and trade-offs
Point-to-point integrations are quick for one or two systems but multiply credentials and failure points as the estate grows. Middleware is one more component to run, but it centralises retries, mapping and monitoring; compare them in middleware vs point-to-point APIs. Salesforce Connect shows external data as external objects without copying it, which suits reference data owned elsewhere, at the cost of depending on that system's availability. Separate orgs per business unit give independence but make a single customer view harder.
Implementation checklist
- 01
Confirm editions and licences
List Sales, Service and Experience Cloud licences and add-ons, and what each edition includes
- 02
Design the data model
Agree objects, record types, ownership and sharing before building
- 03
Set the automation standard
Decide where Flow and Apex are used and who owns each object's logic
- 04
Plan identity
SSO for staff, customer identity for portals, External Client Apps for integrations
- 05
Choose integration patterns
Middleware, events or direct APIs per system, with error handling and replay
- 06
Secure the org
Permission sets, field-level security, MFA and, if licensed, Shield
- 07
Build release management
Source control, sandboxes and a deployment pipeline
- 08
Set up monitoring
Alerts for integration, automation and security events with named owners
Related services and solutions
Salesforce CRM consulting
Scoping and design for Sales and Service Cloud
→Sales Cloud implementation
Pipeline, forecasting and seller workflows
→Service Cloud implementation
Cases, knowledge and contact centre
→Experience Cloud development
Customer and partner portals
→API-led integration architecture
System, process and experience APIs
→Data 360 reference architecture
Unified profiles and activation
→Questions we hear
Is this architecture taken from a client project?
Do we need middleware for CRM integrations?
What should we do about connected apps?
Can AI tools work with our CRM data?
Sources
- https://www.salesforce.com/sales/
- https://www.salesforce.com/service/
- https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_subscribe.htm
- https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm
- https://www.salesforce.com/blog/winter-27-release-architect-highlights/
- https://www.salesforce.com/platform/shield/
Plan your Salesforce CRM architecture
Tell us about your org, users and integrations. We can review your current design and propose an architecture that fits your editions and licences.
