Integration Patterns: Choosing the Right Tool for the Job

Integration Patterns: Choosing the Right Tool for the Job

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

Event-Driven Architecture in Salesforce: Getting Started with Platform Events

Event-Driven Architecture in Salesforce: Getting Started with Platform Events

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

Design with the Exit in Mind: Documentation, Handoff, and Admin Legacy

Design with the Exit in Mind: Documentation, Handoff, and Admin Legacy

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.

Architecting for Reuse: Why I Build with Modularity in Mind

Architecting for Reuse: Why I Build with Modularity in Mind

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.

Metadata Strategy: How I Future-Proof the Org’s Structure

Metadata Strategy: How I Future-Proof the Org’s Structure

Most admins react to requests. I prefer to design systems with a long-term metadata strategy in mind.

That means:

  • Naming conventions for all fields, flows, and objects (FieldPurpose__c, not Custom1__c)

  • Avoiding unnecessary custom objects when record types or junction objects will do

  • Grouping flows by lifecycle (create/update, scheduled, utility) and using consistent labels

Component-Level Security: Not Just a Developer Concern

Component-Level Security: Not Just a Developer Concern

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

Designing for Scale: Why I Default to Declarative Before Code

Designing for Scale: Why I Default to Declarative Before Code

I can write Apex. I often do. But when I design systems, my first question is always: Can this be built declaratively and maintained by a future admin?

Why?

  • Declarative tools like Flow and Custom Metadata are faster to deploy

  • They’re easier to maintain, especially in smaller teams

  • They keep the business logic closer to the surface, not buried in code