Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Salesforce nostalgia as career development

23 Mar 2026 🔖 salesforce professional development databases
💬 EN

Table of Contents

For someone whose last remaining production Salesforce account was deactivated over three years ago, I sure get a lot of value in my career from asking LLMs about Salesforce. 🤔

History of change management in Salesforce

Infrastructure as clicks

In the early 2000s, Salesforce marketed its “ClickOps” vibes for power users with a “real” business to spend their time running, rather than for trained programmers. A sort of Microsoft Access on steroids. Their slogans were literally:

Frustrated developers

Then “DevOps” revolutionized the 2010s, with cool-kid programmers horrified if they found the act of releasing bug fixes and features into a business’s productivity technology (ahem – Salesforce – very much software, even if “programmed” via clicks) less fast or hassle-free than sending cars out the door of a Toyota factory. (I’m not kidding about the Toyota thing. Modern life is all Toyota and Taylorism.)

Salesforce’s plugin authors, known as independent software vendor (“ISV”) partners, complained first. I think that’s because:

  • In-house admins might have assumed that the complex nature of their particular company’s needs within Salesforce meant that it simply had to be a toilsome “change set” experience to rename a field label first in your “development” sandbox, then in your “staging” sandbox, and finally in your “production” Salesforce org.
  • ISVs, whose view of the world was more naturally encapsulated, noticed that “a field is a field is a field – if it’s a field I asked my clients to install, it should be easy for me to update its label in all of my clients’ organizations at once, no matter how special-snowflake the rest of their Salesforce setup might be.” That is, they insisted that Salesforce keep up with “DevOps” trends and provide a better “configuration as code” / “infrastructure as code” experience. Code, not clicks, actually!

Infrastructure as code

Salesforce responded by:

  1. Further breaking apart the XML-formatted file types with which you could, if you were a developer, configure Salesforce Sales Cloud settings like objects, fields, etc.
    • The big one was breaking fields out into their own files, so that two developers simultaneously changing unrelated fields on the same object (a.k.a. data table, for those of you outside of Saleforce-land) wouldn’t step on each others’ toes. This was huge, since most Salesforce custom configuration involves adding a whole lot of custom fields to the built-in “Contact” and “Account” objects.
  2. Introducing the “SFDX” Salesforce command-line interface (“CLI”) tool to go with the new file format specifications.
  3. Introducing new forms of packaging up chunks of configuration setting file, not only to benefit ISVs, but also to benefit in-house Salesforce admins.
  4. Introducing ephemeral scratch orgs, which enabled admins and ISVs to have a truly “cattle, not pets” / “paper plates, not fine china” throwaway experience where they could test proposed configuration changes without stepping on anyone else’s toes. Scratch orgs made all of the other changes above exciting to try.
    • Apparently Salesforce.com actually introduced free “developer edition” instances way back in the mid-2000s, around the same time that Amazon Web Services (“AWS”) launched its pay-as-you-go infrastructure. Dev orgs are plain-vanilla instances of Sales Cloud, with all of the built-in “what you get when you sign up for a brand new paid Salesforce account” objects and fields included – that you can spin up at your leisure if you want to noodle around on a sort of scratch paper with a crazy idea you’ve just had.
      • This means that Salesforce was dipping a toe into the water of “cattle” / “paper plates” half a decade before the phrase was coined, which is awesome, since I swear you still can’t get that kind of “configurator experience” on even a lot of enterprise software invented well after the phrase was well-known. Ahem. Which is probably 95% of why I ramble on about to LLMs about Salesforce like I’m in some sort of cult venerating it, desperately trying to figure out what the equivalent is for whatever product I’m bashing my head against the wall trying to help clients more smoothly release configuration changes into.

Still clicks

All right, I’ll admit, not everyone is Jessie Rymph. No, in 2026, your average in-house admin probably isn’t chunking up “packages” of configuration depending on how tightly coupled the bits and bobs are.

Though arguably, they don’t have to, because they benefit from click-based products like DevOps Center, Gearset, Copado, etc. that use 2010s-era Salesforce coding hacks under the hood to provide 2020s-era admins clicky alternatives to change sets.

The point is, if in-house Salesforce admins run into problems while overseeing their org configurations, although the tooling isn’t perfect, at least now they’ve got a fighting chance of reading Jessie’s blog and trying some neat new “bugfix and feature change management / release” party tricks to reduce the sensation of stepping on colleagues’ toes.

Salesforce jargon as search keywords

Despite my frustrations trying to actually leverage the 2010s Salesforce features above (businesses are mostly made up of non-programmers, so the tension between clicks and code really can’t be understated – I see it play out over and over again everywhere, e.g. flip-flopping whether a solution is better off implemented on Microsoft Power Platform or Azure Function Apps) … I miss them.

But I’m glad I was there to watch them come into existence.

Four years ago, it wouldn’t have helped. But search-oriented LLM chatbots, like the one now built into Google, or like Perplexity.ai, are insanely good at researching based on analogy. So these days, knowing terms like “scratch org” and “sfdx cli” are insanely useful outside of the Salesforce ecosystem.

For example, here’s a real conversation I had recently with an LLM, as I crash-coursed about IBM FileNet P8 before engaging in a consultation to see if I could help improve configurators’ bugfix and feature release management flows:

  • Q: Is P8 kind of like Salesforce Sales Cloud’s vanilla decisions, with built-in decisions about tables you’ll probably need and entity relationships you’re allowed to add? You still have to bring a ton of stuff to it … and maybe allegedly if you’re lucky the “vanilla” model actually is sort of a decent start for your needs but otherwise it can be stupid amounts of overhead? Is P8 also, basically, a “structure things our way, and then we can reliably log for you” promise, helping you glue together things that developers normally just otherwise would manually glue together (file stores, databases, web apps…)?
    • A: Your analogy about IBM FileNet P8 is quite on point. FileNet P8 can be thought of somewhat like Salesforce Sales Cloud in that it imposes a predefined, opinionated structure and a set of core entity relationships (content stores, workflows, users, metadata models) that you must work within. You bring your specialized business logic, configurations, and integrations on top of that core “vanilla” foundation.
  • Q: Let’s talk about test automation and drift-fixing automation. Do configurators need to be somehow running tests within the P8 setup to make sure that the configuration is delivering business value as expected? Do configurators need to worry about drift from planned/documented states or between dev/stg/prd environments?
    • A: Yes, IBM FileNet P8 environments have a large, complex mass of configuration that must be carefully managed to prevent drift. This drift can happen both from planned/documented changes, and from unplanned differences emerging between environments like development, staging, and production. The complexity of FileNet’s multi-component architecture with configuration artifacts, workflows, object stores, security settings, and integrations makes this a real challenge to handle properly.
  • Q: Tell me more. For example, Salesforce finally introduced ephemeral instances called Scratch Orgs to make it easier to have something to deploy version-controlled configuration files into and make sure they work as expected, and then created the “SFDX CLI” to facilitate actually doing deployments both into scratch orgs and into longer-lived environments from said version control repositories. Tell me the modern equivalent for being a FileNet / P8 platform configurator who’s not afraid of code and doesn’t want to have to pay IBM extra money, please.​

I’ve long since lost whatever search history led me to conclude that there’s no equivalent to a dev or scratch org with Sitecore CMS, but I do remember that, once again, my mental model for excellence in business productivity software vendors providing ephemerality involved Salesforce scratch orgs.

  • (Oh. And don’t even get me started on how rare of a treat it is to find a database management system that, by design, makes an auto-truncated ephemeral copy of the table schema, so that you can safely automate testing stored procedures and triggers. Thank you, Salesforce Apex tests.)

So yeah – here I am, no longer working in Salesforce, yet constantly Googling Salesforce. Go figure. 🤷‍♀️

--- ---