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

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

Most teams only think about permissions when something breaks or there’s an audit. I treat permission reviews as part of ongoing system hygiene.

Every quarter, I:

• Run Permission Set and Profile audits using custom report types

• Compare assignments to actual job roles

• Remove “temporary” permissions that were never revoked

When Lightning pages get cluttered, user adoption drops—and performance tanks. This year I focused heavily on page performance optimization while keeping layouts intuitive.

What worked:

• Replacing overused Related Lists with curated Dynamic Related List – Single components

• Hiding low-priority fields and sections behind Dynamic Forms rules

• Moving resource-heavy components (like reports or LWCs) to secondary tabs