I recently published a new course on Pluralsight: “Salesforce Development: Getting Started” which is designed to be one’s very first introduction to Salesforce for developers and admins. It starts out in a way that most would find familiar: how to sign up for a developer org, an introduction to orgs and metadata – you know, the way everyone learns Salesforce.
But then I do something different. I talk about metadata, the source of truth, and Salesforce DX (SFDX). In fact, most of the course is about SFDX and how to use it. Not only that, but I’m very intentional about not focusing entirely on code. Automation and other metadata is given more or less equal time and emphasis. In fact, the alternate title for this course is “An Admin’s Guide to SFDX”.
You see, SFDX may draw on techniques familiar to software developers, but SFDX is not about managing software or code. SFDX is about managing metadata. All types of metadata.
SFDX is not about managing software or code – SFDX is about managing metadata
I truly believe it should be the among the first things every future Salesforce developer and admin learns – maybe the very first thing.
Ok, the developer part makes sense. But admins?
Yes. Hear me out.
We all know that it’s better to learn to do things correctly the first time, than to learn the wrong way of doing things and then have to unlearn those bad habits. In the developer world, that’s why my mantra has always been “there is no code but bulk code”. Teaching someone to write single object code and bulkify it makes no sense to me – if you learn bulk patterns from the beginning, you’re far less likely to run into trouble.
When it comes to managing metadata in orgs, every Salesforce admin and developer knows what a nightmare it can be. People creating automation and making changes directly in production. People overwriting each other’s work on sandboxes, or worse, refreshing sandboxes and wiping out work. Integrating changes from multiple teams and sandboxes and trying to coordinate that effort. Not knowing who made changes in an org, or why. The presence of automation, fields and reports that you don’t understand and dare not remove because you have no idea what they do. This is sometimes called “Happy Soup” – a jumble of mixed metadata that makes an org function – as long as you ignore the burnt crust at the bottom of the pot.
Salesforce DX provides the approach, tooling, and processes to solve all of those problems. Software developers, at least those who are familiar with modern software development processes, understand this – which is why we have adopted it – no, embraced it, with great enthusiasm. So teaching future Salesforce software developers SFDX first, is obvious.
But software development is just a tiny part of an org’s metadata, and adopting SFDX for source won’t solve the greater problem. To cure org metadata chaos demands that all of an org’s metadata be managed in SFDX, and that requires moving admins over to SFDX.
I know that sounds scary and intimidating to some, but I promise you it isn’t. Almost everything you’ll ever do in SFDX involves about a half dozen simple commands. Then perhaps a half dozen more for the source control system. And you would be using a GUI for those commands anyway, so there’s nothing to memorize. Anyone who can handle being a Salesforce admin, can certainly handle SFDX.
Teaching new admins without covering SFDX only ensures that today’s chaos will continue. But if new admins and developers start with SFDX, they’ll begin their career on the first day knowing that the right way to change metadata in any org involves comments on every change so you know why it was made, knowing who made every change, and the ability to go back and look at the state of your org at any point in time. There won’t be a field, report, workflow or page layout that doesn’t have a complete history. If someone overwrites another person’s work, you’ll know who did it what they changed and why, and be able to restore the previous state if necessary. Sandbox refreshes will be no big deal – you’ll never lose metadata. And if someone needs to experiment on something, they won’t do it in production, or even fight over access to a Sandbox – they’ll be able to spin up a temporary org that matches production and test things out there.
That’s what modern software development looks like in Salesforce today. It makes no sense at all not to apply that approach to all metadata. That’s why an SFDX first approach is the future of learning and teaching Salesforce.
That’s why I built the course the way I did. I encourage you to adopt that approach, whether using my course or other sources. SFDX is the future of managing metadata on the platform, and that future can’t come soon enough.
Check out “Salesforce Development: Getting Started” on Pluralsight (you can sign up there for a free trial if you don’t already have a subscription).
