- You shall work under executives’ blessing
- If the executives don’t use Salesforce, leave
- You shall track projects, requests, and bugs in tickets
- If you don’t track tickets, start
- You shall gather requirements before developing
- If you are not allowed to gather requirements, leave
- You shall develop in environments with a lifecycle
- If you develop in Production, stop
- You shall favor customer needs over design
- If you disregard customer needs, get over yourself
- You shall master one datum in one place
- If you modify a datum in multiple places, consolidate
- You shall not lie in the data
- If you lie in the data, redesign
There’s no shortage of Salesforce Commandments out there, but I like these seven because I
- wrote them from my own hard-won experiences
- recommend a course-of-action for each
- ditched pretentious language (“thou shalt”? no thanks)
- commit to revising them if I meet a sufficiently-compelling case (suggestions welcome!)
I first put it together in 2015ish, got it into its current shape in 2020, and presented it at an OpFocus DevOps roundtable in 2021.
Props to Steve O’Neal for the phrase “lie in the data”! Captures an important concept and sounds juuust a smidge Biblical.
Kudotek v2.0 
oh, one thing that came up in that 2021 roundtable (https://opfocus.com/engage/elevating-salesforce-devops): “why isn’t there a ‘you shall document your org’ commandment?”
I agree that documentation is *great*.
but in my experience, unless someone’s actual job is documenting, *documentation obsolesces fast*.
in practice, I emphasize writing good tickets, reqs, and solutions (Commandments #2 and #3), and then connecting bits of Salesforce config to those tickets, reqs, and solutions–by, say, putting a Jira ticket number in a new object’s Description field.
tools like Copado (which Brian Wainwright praises in that roundtable, and I’ve similarly come to adore) automate the “connecting config to ticket” thing, but manually adding Description comments is always a good habit!