London’s Calling 2026: Modern Salesforce Architecture Without Starting Again

Today I’m speaking at London’s Calling about a topic that has been occupying much of my thinking: how we modernise Salesforce architectures without pretending we can simply start again.

Diagram: Changing experiences need stable business decisions
Modern Salesforce architecture separates fast-changing channels from reusable service contracts and trusted foundations.

TL;DR

Key message: Modern Salesforce architecture is not about rebuilding from scratch. It is about understanding existing estates, reducing architectural congestion, and evolving systems in a way that supports future change.

Why it matters: Most Salesforce orgs have accumulated business logic across many platform features over time. Without a clear architectural approach, this complexity makes change slower, riskier, and harder to govern.

Key takeaways:

• Most long-lived Salesforce orgs need modernisation, not replacement.

• Architectural complexity often comes from business logic being distributed across many platform components.

• Focus on understanding business behaviours and capabilities, not just objects and fields.

• Move toward named services and reusable patterns for key business functions.

• Modernisation improves adaptability, governance, AI-readiness, and long-term maintainability.

Digging Deeper

This page is here as a companion to the session. I’ll use it to share resources, references, follow-up material, and further thinking for anyone who wants to go deeper after the talk.

The central idea is simple: many Salesforce estates do not need to be replaced. They need to be understood, restructured, and made easier to evolve.

Diagram: The order of execution is not an architecture.
In mature Salesforce orgs, modernisation starts by separating shared data from owned business behaviour.

Most long-lived Salesforce orgs were not badly designed. They were designed for the problems, teams, budgets, and platform capabilities of their time. But over the years, business logic spreads. It appears in triggers, Flows, validation rules, record pages, managed packages, integrations, reports, permission models, and human workarounds. What began as useful flexibility can become architectural congestion.

In the session, I’ll explore how we can move from object-centred thinking alone toward business patterns and named services. I’ll use case triage as a practical example: work arrives, is classified, prioritised, routed, governed, presented, updated, closed, and communicated. That behaviour may be implemented through objects, fields, queues, Flows, Apex, Omni-Channel, SLAs, notifications, and pages. The architecture challenge is understanding the business behaviour those components collectively express.

That is where I believe modern Salesforce architecture is heading: less logic hidden in trigger paths, and more intentional services for capabilities such as VIP routing, complaint escalation, partner support, entitlement checks, and case prioritisation.

This is also a positive message for the Salesforce community. The future still needs architects, admins, developers, consultants, and product owners who understand the platform deeply. But it asks us to stretch: to think in patterns, services, governance, data, AI-readiness, and long-term change.

Modernisation is not a rebuild. It is the discipline of making the existing estate understandable, adaptable, and ready for what comes next.

Resources

I’ll add links and materials here after the session, including:

• Slides from the talk

• Example pattern definitions

• Case triage architecture notes

• References to service-layer thinking and Apex Enterprise Patterns

• Follow-up articles on modern Salesforce architecture