Jason Lantz’s Post

Ever wanted to start a new project in scratch orgs that depends on some third-party managed packages, either open source like DLRS or from an ISV? Maybe you also want to mix in some internal modules and packages too? I'm really excited about this new feature of D2X Platform. It's a completely rewritten implementation of the concepts from CumulusCI's dependency engine, extracting the obscure magic into a fully transparent report and even more data from the backend API: https://lnkd.in/gJEu9AwG No more files to edit. Get a static map of all your project's current dependencies prebuilt for every commit.

🐣 The Salesforce Digital Twin Chicken and Egg Challenge... I'm hearing more discussion about the concept of the Digital Twin as it relates to Salesforce DevOps. A Digital Twin is a virtualized replica, easily created and destroyed on-demand. This virtualization, if done right, enables many of the traditional DevOps best practices the Salesforce ecosystem has been struggling to adapt to our world for many years. But, we have a chicken and egg problem: Which comes first, the org or the blueprint to create a Digital Twin. Most of the discussion I've heard about a Salesforce Digital Twin falls into the first category: retroactively construct a high-fidelity design to replicate the functionality of the production org. Let's call this the Chicken -> Egg approach. You need the org (chicken) to create the blueprint (egg) and then a chicken -> egg -> chicken process to recreate an always imperfect replica. The original chicken is still the source of truth that everything else tries to adapt to. I hear little discussion about the Egg -> Chicken approach where all development work starts first on the Digital Twin blueprint (the egg). The advantage of this approach is that there's no tech debt to back-port into the Digital Twin blueprint. The Digital Twin blueprint in source control is the source of truth for what's built. Thoughts? Bad chicken jokes? ;) Edit: From the comments, I'll clarify that I'm not proposing all metadata should be created and edited as source XML files. I mean every iterative improvement starts in a clean scratch org created from the currently defined automated blueprint in source control. Work is easily captured back to source from that org since the work is isolated. The goal is to capture the changes back into the blueprint in source control so they become part of all new scratch orgs. It doesn't matter how you make your changes in that org.

🎉 Ever felt like mapping DORA metrics to Salesforce DevOps feels like somethings not exactly aligned? This is an exciting effort... I've had this discussion with many people in the community over the years. I know my world adds the extra complication of ISV distribution to thousands of orgs, but I've heard many express the feeling that we need some sort of adapted version of DORA. I kind of feel this would be along the lines of the sometimes minor differences with huge impacts on the DevOps process between deploying a complete infrastructure and deploying a layer of configuration into a persistent instance. Things like, for example, you will never be able to do a blue/green deploy of your Salesforce org. I'm excited to see the outcomes of this collaboration.

API's are great and all, but there's nothing like a nice web user interface for turning really complex functionality into an easy and accessible user experience for everyone. CumulusCI's dependency engine is one of its most powerful and underused features. With a few lines of simple YAML, CumulusCI can build recursive dependencies on other CumulusCI projects' GitHub repositories, Salesforce packages, and unmanaged metadata from a url or subfolder in GitHub. But, all that power was mostly only available through the CLI, limiting its reach to mostly just developers. I'm really excited to be part of changing that story and letting your whole Salesforce team tap into the power of self-service org creation and configuration.

I've long identified as someone who faces at times pretty extreme Imposter Syndrome. It was incredibly common at .org, but it's something I've felt throughout my whole career. Two recent events have caused me to change my understanding of my own brushes with Imposter Syndrome and shed that self-identity from my conscience (or at least start trying to): 1. I was diagnosed with Adult ADHD and started medication 2. I read about and understood a new term: Toxic Shame The two are quite intertwined. I've struggled with the feeling that I didn't belong for most of my life. Like there was something so different or weird about me, not my choices, not my actions, but just who I am, and especially how my brain works. Finally getting over my reluctance to consider ADHD, I now understand there's nothing wrong with me, I'm just wired differently. But the real breakthrough was coming to understand that my own, at time self-deprecating, joking about Imposter Syndrome was really just another way of saying I was suffering from Toxic Shame. So what is Toxic Shame? First, both guilt and shame are normal emotions. We all feel them. The distinction is nuanced, but I see guilt as more about your internal ethics where shame is more about external morality or the perception of others. Both can be good things to feel. When we do something wrong, they motivate us to do better. Toxic Shame is when shame becomes a demotivating force, when that feeling starts to become part of your identity like there's something fundamentally flawed about you. Here's a hint, there's not anything wrong with you ;) Keep an eye out for that toxic shame self talk though. Confront it. You might discover you're capable of way more than you ever imagined! Hence, I no longer identify as someone with Imposter Syndrome. Realizing it was actually Toxic Shame helped me see it less as a joke and more as a barrier to overcome.

If Org Profiling and scalable Scratch Org creation aren't exciting enough, check out the new D2X Dependency Composer. Resolve CumulusCI style dependencies from anywhere with a simple API call...

Sometimes customer support goes so bad that it's a good learning experience. This iteration brought to you by Intuit... Quickbooks merchant accounts apparently have a policy of a 5 business day hold for the first transaction. The second, even while the first is held, goes right through in 1 day. The amounts don't matter. Unfortunately for me, not knowing this meant a large invoice payment made last Friday still isn't available. OK, yes, I read the agreement when signing up and should have known that. That's not the issue. The issue is that when I called on Tuesday to speak with a rep to find out when the money would come through, he told me it would absolutely be in my checking account today, Friday. I asked if that's still the case with the Juneteenth banking holiday. He confirmed it was. Today, no deposit to checking account, so I try their chat support. I'm told the prior rep was likely just new and gave me incorrect information, about an important financial matter mind you. After about 15 minutes of non-responsive answers and no clear indication on when the money would actually be deposited. At the end of the chat, the rep tried to pitch me on their Payroll solution! I let her know that I'm questioning staying on Quickbooks at the moment and wouldn't even consider anything else until they resolve this issue. While waiting for a supervisor to call me back, I get a call from Quickbooks. It's a sales rep wanting to set up a demo of Payroll because I had expressed interest!!! 💡 Sometimes overly integrated can be a bad thing, at least without the right human context around it. Trying to upsell an upset customer is a fail for sure. Quick aside: If you're setting up Quickbooks, run a $1 charge through your merchant account to clear this 5 day hurdle!

✅ Another major feature checked off the D2X Cloud pre-launch roadmap! D2X Cloud now has a fully asynchronous scratch org generation service built into the platform. Why is this important? D2X Cloud is a multi-tenant platform instead of just a CLI. If you're just spinning up one scratch org in a build, the fact that your worker is waiting while the platform does the work of spinning up an org isn't that costly. Now imagine doing that in a platform spinning up thousands of scratch orgs at once. Async is essential to scale. 🎉 Even better, building this feature spawned another even better one! D2X Cloud now also includes an asynchronous Org Profiler service that builds a snapshot of an org's settings and configuration relevant to the deployment process but with no PII data included. Imagine debugging a deployment failure with all the relevant information about the target org at your fingertips, or better yet, in the hands of AI to help you resolve the failure. Here's the docs on what's included in an Org Profile today which will surely continue to grow. Got recommendations of what else to include? https://lnkd.in/gfHrCcBn