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

Cross-object formulas can be elegant—or they can become performance bottlenecks. The difference is in how you build them.

I’ve learned to keep them lean:

• Limit how many relationships you traverse (e.g. Parent.Parent__r.Contact__r.Email)

• Use text outputs instead of nested IF statements when possible

• Avoid unnecessary references to formula fields within formula fields

You don’t need Apex to schedule work anymore. Scheduled Flows are robust enough for 90% of my time-based automation.

Use cases I’ve implemented this year:

• Daily digest emails based on queue assignments

• Automatic reminders for unfulfilled reservations

• Weekly maintenance tasks like flagging stale records