Not all Apex needs to be abstract and layered—but when complexity grows, design patterns are how I keep things clean.

The patterns I reach for again and again:

• Trigger Handler Pattern: One trigger per object, always. Handled via a framework class.

• Service Layer Pattern: Keeps logic centralized and testable

• Strategy Pattern (with interfaces): For dynamically applying rules based on context (e.g. by Record Type or membership category)

Great systems enforce standards without punishing innovation. I use Custom Metadata to define and enforce those standards across the org.

Examples from real projects:

• Controlling which Record Types can trigger which Flows

• Defining available options for dynamic automation menus

• Centralizing logic that multiple Apex classes reference

Salesforce gives you a lot of ways to integrate—REST API, Apex callouts, Named Credentials, External Services, and more. The trick isn’t knowing what’s possible. It’s knowing what’s appropriate.

My go-to rules:

• For real-time sync, I use REST callouts with Named Credentials

• For asynchronous or high-volume data, I lean on Platform Events or Change Data Capture

• For user-initiated actions, I’ll consider Screen Flows or LWC buttons with Apex

When systems need to talk to each other asynchronously, I reach for Platform Events. They’ve become a core part of how I design integrations and decoupled automation.

Why they matter:

• They allow publish/subscribe communication between systems

• They’re built for scale and resilience, not just speed

• You can trigger flows or Apex in response to events—with zero user action

No one talks enough about this: Someday, you won’t be the admin here.

Whether it’s growth, promotion, or moving on, the real sign of a great admin/dev isn’t just what you build—it’s what you leave behind. That’s why I document everything like I’m onboarding my replacement next week.

At this point in my Salesforce career, I don’t just build solutions—I design systems. And the systems that age well all have one thing in common: modularity.

Whether it’s Flows, Apex classes, or Lightning Components, I follow a core principle:

Build once, use often.

Component visibility in Lightning pages isn't just about page layout—it’s about security and context-aware experiences.

This year I’ve been refining:

• Field-Level Security enforcement in custom LWCs

• Record Type and Profile-based visibility on Lightning pages

• Using custom permissions to show/hide entire page components