Make failure recoverable
Every distributed flow needs an answer for timeout, retry, duplication and partial success.
Architecture
How I think about enterprise Salesforce systems.
These are anonymised examples of the kinds of architecture problems I work on. The emphasis is on decisions, trade-offs and operating behaviour rather than client-specific implementation details.
01
Enterprise integration
Salesforce ↔ SAP order lifecycle
A multi-system flow where Salesforce initiates business actions while SAP remains the system of record for downstream commercial processing.
SalesforceUI · business context · orchestration trigger
→
Integration layerrouting · transformation · retry handling
→
SAPpricing · order processing · master data
Design concern
Multiple dependent calls can turn a single user action into a fragile chain if transaction boundaries are not explicit.
Architecture choice
Keep Salesforce focused on customer and process context while middleware owns cross-system routing and transformation.
Failure strategy
Use correlation IDs, retriable operations and visible error states so failures can be recovered without duplicate business transactions.
What I watch
Callout limits, response times, idempotency, partial success, data ownership and operational monitoring.
02
Service architecture
Service Cloud & Omni-Channel routing
A support architecture where the challenge is not simply assigning work, but balancing capacity, priority, skills and customer context.
Customer channelsportal · chat · service requests
→
Routing & automationpriority · skills · capacity
→
Service teamagent workspace · next action
Design concern
Routing rules become hard to operate when business priority, agent availability and exception handling are mixed together.
Architecture choice
Separate assignment logic, service automation and agent experience so each can evolve independently.
Operational focus
Make queue behaviour and fallback paths observable rather than relying on hidden automation.
What I watch
Capacity models, re-routing, ownership changes, duplicate case creation and automation recursion.
03
Engineering architecture
Reusable Apex delivery patterns
A codebase scales better when developers do not have to reinvent trigger control, logging, async orchestration and configuration for every feature.
Entry pointstrigger · LWC · Flow · API
→
Domain & servicesbusiness logic · orchestration
→
Platform serviceslogging · async · metadata
Design concern
Feature-by-feature code often creates duplicated logic, inconsistent error handling and test fragility.
Architecture choice
Use clear layers and reusable platform utilities while resisting frameworks that add abstraction without reducing complexity.
Quality strategy
Make behaviour testable at service boundaries and use metadata for genuinely variable business configuration.
What I watch
Bulkification, transaction state, recursion, async limits, log usefulness and coupling between UI and domain logic.
Architecture principles
Prefer explicit boundaries
Know which system owns the data, which layer owns orchestration and where transformation belongs.
Optimise for operations
A design is incomplete if support teams cannot understand what happened when something fails.