For years, I focused on building solutions. Now I focus on defining the right problems—and sometimes, that means saying no.

Not all requests belong in Salesforce. Not all automations need to exist. The mark of an architect isn’t how much they build—it’s how strategically they build.

When people think of External Objects, they think data sync. But I’ve started using them to improve the user experience in Salesforce.

Examples:

• Viewing external inventory or availability directly from a record page

• Displaying past transaction history from a billing system

• Creating read-only snapshots of data that doesn’t need to live inside the org

Permission Set Groups are one of the cleanest admin upgrades Salesforce has introduced—and I now use them to enforce structure and clarity across our org.

Instead of assigning a dozen permission sets individually, I:

• Create logical groups like “Core Consultant Access” or “Service Manager Tools”

• Add or remove permission sets centrally

• Apply muting permissions when necessary (yes, you can subtract access too)

Both Platform Events and Change Data Capture (CDC) are great tools for loosely coupled integrations—but they serve different use cases.

How I decide:

• Platform Events are best for intentional actions (e.g. “ReservationConfirmed”)

• CDC is best for passive data sync (e.g. whenever a Contact is updated)

If there’s one rule I apply religiously in my org: hardcoding is technical debt.

Whether it’s Flow logic, Apex classes, or email templates, I aim for loose coupling:

• Use Custom Metadata Types or Custom Settings for key values

• Reference Labels, not static strings

• Pull IDs dynamically using Custom Labels or SOQL selectors, not copy/paste

The best Salesforce orgs are built like modern software projects. That means embracing CI/CD, even if you’re a solo admin.

My current setup:

• All declarative and code changes tracked in GitHub

• Pull requests trigger validation deployments to a sandbox

• Static code analysis runs using PMD and Prettier

• Deployments happen via SFDX CLI scripts or GitHub Actions

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