Prodly - Scott (00:10.496)
Welcome everyone back to another edition of Prodly did you know I am your co-host Scott Teeple. Very excited to bring you yet another edition where we're going to be talking about scratch orgs and change types.

So with me is Jen, as always, my co-host, and another edition where we're bringing Max in. Really excited to have him back to be able to share his overall knowledge. Don't think we need to stop and do any formal introductions, but Max, if you'd like to say a couple of words.

Max Rudman (00:38.272)
Okay.

Max Rudman (00:43.777)
Thanks, Scott, really delighted to be here again, and of course, I'm Max CEO of Prodly, previously founder of Steelbrick, and looking forward to another fun conversation.

Prodly - Scott (00:58.208)
Perfect. Yeah. So as I said, Prodly has scratch orgs and change types. So some of you may be out there like kind of scratching your head, pun intended. What is a scratch org and what is Salesforce's, ideas around that? And then a change type. You've never heard of that. Well, that's really something that is, is Prodly and how we're going to extend that. And that's exactly what we're going to get into a little bit today.

So Prodly does more than just move complex data. I hope you're starting to get the trend here with Prodly did you know? But why should you trust Proudly for more than just that data piece that you know and love us for? But Max let's get into a little bit of this conversation about Salesforce's vision and what a scratch or.

Max Rudman (01:40.636)
you

Max Rudman (01:44.759)
Yeah, so Scratch Org is sort of the next generation of Salesforce, part of Salesforce's vision for the next-generation Salesforce developer experience, right? That's what that's at the extents for, by the way, it's Salesforce developer experience. It's actually built on their new kind of infrastructure database architecture called Sayonara, which is...

A fun fact is, that Sayonara is goodbye in Japanese as in goodbye to Oracle, which is what Salesforce had originally been built on. And it's just really fast. Sort of uses a different database architecture and that's what enables these scratch works to spin up quickly. So that's part of it, like performance, but also I think just.

Division around scratch works and you know, kind of aligning more closely with what your sort of normal developer experience would be outside of Salesforce where you have your local work workstation, right, that you write code on and you pull source code from the repository and then, you just kind of have your local

Like server writing, the web app that's, let's say that you're developing, you make some changes, right? You commit those changes and then you can blow out that whole local directory and replace it with something else. But the point is it's sort of like temporary and transient while you're making changes, right? So that's the same paradigm behind the scratch works to kind of drive that source-driven development paradigm that Salesforce is trying to introduce into Salesforce development.

Prodly - Scott (03:35.574)
Perfect. So then what do we understand about Salesforce's vision and how organizations should be utilizing them within their day to day business operations?

Max Rudman (03:45.797)
Well, as I said, I think it really kind of goes hand in hand with this transition to a source-driven development paradigm as opposed to an org-driven development paradigm, right? Where all your Salesforce config is driven from a source control repository, a Git-based repository, or it doesn't have to be Git, but that's sort of the prevailing standard in the market right now. But the point is all that config is actually mastered, not on Salesforce.

Org production org but it's mastered in a Git repository, source controller repository and then you're sort of deploying into orgs to match the repository. Now I would say the big advantage of that is if something should go wrong, God forbid, either there is some kind of disaster or you know, kind of an accidental, you know, overriding of a change or maybe you deploy the change that.

Happen to break something and you need to get the system back up quickly, then you can do what's called a rollback or restore from a source control repository and bring your org back online. If you are on the source-driven development paradigm, that's really hard to do, right? Because then you're to have to go look for an org that doesn't have the change that broke it, which is a lot more.

A lot more difficult and a lot more time-consuming and therefore increases your downtime.

Prodly - Scott (05:19.414)
Yeah, so I guess let's introduce change type here a little bit. I know I said it a couple of seconds ago. What is Prodly's vision for these scratch orgs that Salesforce allows and then what's a change type?

Max Rudman (05:31.621)
Yeah, so they're kind of different, different but related concepts and sort of one builds on the other. Right. So, when we say Prodly has scratch orgs, what we mean is not that we have our version of scratch orgs. What we mean is we support scratch org-based development. And why, what does that mean? Well, scratch orgs are sort of the next-generation architecture. They're really fast, but

One of the big problems with them is they're sort of really bare, right? A scratch org in its purest form is just an org. There's nothing in it at all. A sandbox at least has the metadata, right? A full copy of the metadata from whatever environment it's being spun from. Scratch.org doesn't even have that, right? That's one problem. Two there really is no UI.

To create a scratch org unless I like a sandbox, right? With a sandbox, you go to set up and you have templates and it's a GUI. GUI to spin up a sandbox with scratch org, you would have to use CLI, command line interface, part of this FDX, right? To create this, there are no different settings that drive it. So not an experience that lends itself to a citizen developer type of work.

So the first bit of functionality that we have is a UI to create a scratch work, right, that a citizen developer or a non-developer can use. And we're not just talking about creating a scratch work, we're also talking about seeding it with, of course, data, which is our bread and butter, but also metadata in this case. And now...

I will point out that Salesforce has continued to work on this, and made a lot of progress in supporting scratch work development and making it a lot easier. There's nothing like snapshots, which you can configure. It's a snapshot of an org with no data in it, but it's just metadata, so at least that part is easier. But I'm pretty sure you still have to use the command line interface to spin it up. So we're putting a UI on...

Max Rudman (07:57.48)
Just the process of creating a scratch work which makes it accessible to less technical users. So that's one feature of Broadly. That's a big value. Change types are something different and it's related but it kind of builds on this concept of scratch work and makes it easy to spin up dev environments. And it's, I would say, a higher-level abstraction.

So it's not really specific to Scratchworks, but it's really about making dev environment creation faster and easier and more accessible to less technical users, one, and two, abstracting away the complexities of such a process. So change types are really, and the reason it's called change types is sort of built around this concept like, hey, what kind of change are you making?

Right, are you...

Making a change to flows in the sales cloud? Are you making a change to your CPQ implementation? Or maybe even more specifically, is it a change to a product catalog? Or is it a change to the templates, right? Like the granularity of a change in what kind of, know, how you want to structure these changes is up to you. But the vision behind it is like, hey, you define what these changes are for you.

When I say you, meaning an admin or an architect, somebody who understands the nuances of the data model and the metadata that's involved in a particular kind of change. And they define these change types, change types once, right? And as part of that definition, they specify what kind of environment it needs to be created in. So is it a scratch word?

Max Rudman (09:56.429)
Maybe it's a sandbox, if it's a long-running change, right? Perhaps it makes more sense to do it in the sandbox because one of the features of Scratchworks is they're transient, right? They, I think, you specify the duration of a Scratchwork, but I think, I believe the most they can go on is 30 days. So if you have a long-running project, for example, like, you know, in the RIP implementation, and you need to have a sandbox, that Prodly doesn't work for you, right? Because, you know, that type of project is more certainly going to go on for longer.

30 days. As part of the change type definition, you'd specify what kind of development environment you want to do it in, Scratch org, Standbox, Pro, dev, dev pro, partial, whatever. You specify the kind of metadata that you want to have in there. If it's a scratch org, right? Because Sandboxes will have all of it anyway. But you can specify the metadata for the scratch org. Or even if it's a sandbox, you may say, like,

It gets spun up from production, but I want to overlay certain kinds of metadata from a different environment or from a version control repository, let's say. Right. So there's also some nuance and you can do that. And then the last piece is you, you, you specify what kind of data you need for that change. Right. And if it's CPQ product, analog change, well, yeah, your products, you need product options, right? Product rules, price rules, et cetera.

If you're making changes to the standard sales cloud, then maybe you're tweaking the lead-to-opportunity conversion mappings. Well, you probably don't need your products and product options, right? You Probably just want to have a sampling of accounts and leads and opportunities and contacts that you can test out, And then as a user, right? And by user we mean,

whoever it is that's making the changes, you really don't know about any of it. You don't need to know about what you need to have in your development environment and how it's set up. All you do is you just pick a change type that applies to you and click Go. Or better yet, you don't even do that. The change type was already assigned to the change request or a work item that you're working on.

Max Rudman (12:19.504)
And by the time you come into work, in the morning, or whenever you come into work, a fully configured, fully functional, dedicated dev environment is already spun up and ready for you just for that work item with everything you need and nothing that you don't.

Prodly - Scott (12:41.302)
Yeah, and that's exciting, especially when you think about not just having it available, but also seated with production data so you know that developers will be working as close to production as possible. So you're not bringing in other stuff, other factors, other variables that could cause when you go to product.

Max Rudman (13:00.804)
That's right. You're isolating exactly. That's obviously the best practice, right? Is it to have a fully isolated dev environment just for that work item or just that work stream, know, whatever that granularity is, up to you. But exactly right. It's fully isolated and it has everything that you need from both metadata and data perspective. And it doesn't have to come from just production, right? It could be a composite of multiple sources.

Across metadata and data.

Prodly - Scott (13:34.694)
Yeah, and not to mention installing packages too, is really, really exciting. So, but yeah, Jen, so, know, as you think about Prodly and our, I guess, UI piece of it, right? Like, what would you expect, right? The basics of a Scratch tool. Talk us through a little bit of these features that you would find by using Prodly for the creation.

Jenn (14:01.072)
Yeah, so this slide here does list each of those pieces individually. But essentially, these are the basics of what you'll need if you need a Scratch org tool. So obviously, being able to create a Scratch org is first and foremost. We kind of talked a little bit about the configuration piece as well, being able to configure that org how you need it, authentication and access, and of course, being able to authenticate that environment, and connect it to run.

Prodly - Scott (14:17.814)
you

Jenn (14:31.058)
other deployments and then monitoring who has access to it, and who can access it. Environment management of course. Source tracking version control which Max also touched on a little bit earlier, but being able to you know connect to a VC repository and continue your development through your pipeline.

Metadata data deployments, right? We're talking kind of populating that metadata in the org upon creation, and then of course also preceding it, so you don't even need to really run a post-seeding deployment. Custom scripts, automation, being able to go on and automate that. And then of course the UI, which is kind of what we're going to be showing in the demo. So we'll be able to walk through that.

Prodly - Scott (15:15.286)
Yeah, and I think the thing that I really love about this right in Max, you talked about the CLI and getting it done. This is none of what you get in that right like you just getting it created and then right. How do you then go and start applying and how do you start using it Prodly is really kind of taking care of all of this right with all the things that you already know and love about us. When you think about authentication access, environment management, all that kind of just gets on him. Autogenatically is the word I love to use here kind of behind the scenes. It kind of sets it up for you.

It's really, really awesome.

Max Rudman (15:47.33)
Yeah, and I think a really important point here is, in our ultimate vision, you actually are kind of using change types programmatically, through the CLI or through the API. The ideal state is that the end user, the developer, the admin, and whoever is making changes, don't even see change types. It's something that is sort of like the plumbing behind the scenes.

You know, all they really know is they get assigned a work item, a change request to work on. And as part of that assignment, right, automatically everything just works and it just gets set up. So it's kind of like the Apple value proposition, right, it just works.

Prodly - Scott (16:37.898)
Yeah. Yeah. So, Jen, you've got a couple of questions here you wanted to go through with Max.

Jenn (16:43.448)
Yeah, yeah. So normally when we do showcase our Scratch orgs change types to our customers, some questions do come up. So we want to take a moment to highlight those here. So these are questions that our customers have asked in the past. So why Scratch orgs over sandboxes? Why are they recommended?

Max Rudman (17:03.686)
Yeah, so again, the big caveat here is that I don't think I would say that scratch orgs are always should be used over sandboxes, right? As I pointed out, there are some use cases where sandboxes actually make more sense. In fact, are the only choice that makes sense. But why scratch org, I would say, is recommended for most use cases is, you know, again, it's really about the speed, frankly.

Right? As you and many, maybe most of our listeners know, sandboxes can take a while to create. It could be anywhere from several hours to sometimes days, and we've even seen a week-long sandbox creation turnaround time. And this is because the sandboxes, you know, they get put in the queue, and depending on how busy the instance is.

Data is getting copied, right, not just by you, but by other tenants in the pod in the queue before you, right, it can take, it really takes a long time. And because scratchers, scratchers are using that new database architecture that I talked about, right, they are much, much faster. We're talking on the order of, you know, minutes, right? Could be seconds if it's kind of a vanilla scratch work, right? I was like,

Installing the managed packages takes Prodly the most amount of time and that could take a little while. Depending on how many of those you have in your org, right, that could extend the time, but there are orders of magnitude faster than a sandbox. And so, so why do you need that speed? Well, it goes back to this best practice of creating dev environments that fully isolate your particular workstream or even individual.

Work item and so if you want to follow that best practice then you need to create a lot of development environments right and so that's where the performance comes into the picture right if you're creating a lot of developing environments then you can't be waiting for days and weeks right for them to be created

Jenn (19:21.24)
And just to kind of reiterate, so the best practices, at least Salesforce recommended best practices, are to have individual work items being worked on in individual scratch work environments. Is that correct?

Max Rudman (19:37.714)
I think it's yes, yes. And it has to do with, so again, let's kind of unpack why that is, right? So Scratch orgs, and maybe this is your next question that's on the slide is, mean, Scratch orgs itself don't have many benefits, right? It's just an org, right? At the end of the day, The end result is kind of the same. You're making changes to an org in a dev environment, a dev org.

Where you can test them out and then queue them for promotion to the next org in your pipeline. So, but then kind of working backward from that is, right, like if you are following the best practice of creating like this feature, feature branches and spinning up separate organs for your separate work streams or even separate work items, then you need to spin up these organs.

Much more frequently and you need it to be done faster. So then the question is, well, why do I want to isolate my work and why do I want to create a separate dev environment for every work stream, work item, whatever? Well, this goes into the downstream impact of not doing that, which is the less segregation you have,

the more you're piling into a shared development environment like a full copy sandbox or even partial sandbox, the more concurrent separate workstreams, and work items are getting worked on by the more developers in that work, the higher the likelihood, the higher the chances of you running into merge conflicts and overriding each other's changes. So that's really kind of like when you think about scaling.

Right, that's really the issue, right? As you scale, you have more cooks in the kitchen. You're gonna work on more things at the same time. You're gonna have more concurrent work streams. So if you don't spin up more environments and isolate the more, you're gonna have problems downstream with mergers and things getting overwritten and such.

Jenn (21:48.325)
Right. So to kind of sum that up, it's not the scratch org itself, more the process that you build around it. Yeah.

Max Rudman (21:54.136)
Exactly. Exactly.

Jenn (21:56.558)
Amazing. So the next question I know we kind of touched on this a bit. If my team is growing, how can Scratch Orgs benefit my organization to save me time and money? We definitely talked a little bit about the time. But how about the money aspect? How could using these Scratch Orgs in your process kind of your team time and money in the long run?

Max Rudman (22:20.099)
Well, I'll start by saying that time is money. Right? So just by saving time, you are saving money.

Other than that, you can Prodly optimize your sandbox spend in some ways. Right? So kind of the brute force way of doing this. And this is not just about scratch works. This is really more on sandbox management and data seeding specifically. The brute force approach is just to buy more full-copy sandboxes, which are obviously, you know, very expensive, or even partial sandboxes, which also cost money.

So by leveraging Dev, DevPro, and Scratch Orgs, which are free, you are able to optimize your spending. I'm not saying you should not have a full copy sandbox or even multiple full copy sandboxes, on the complexity of your pipeline and your process. But you don't want those to be taken up, or consumed by your Dev environments. Those should be your UAT, your staging, something much, much later in the pipeline.

Jenn (23:25.713)
That makes a lot of sense. Okay, and then the last question we have is, are there any considerations before getting started with change types?

Max Rudman (23:27.097)
it

Max Rudman (23:35.917)
Well, the biggest ask Prodly is for you to think through what are the kind of changes that you're making what those changes need from both metadata and data perspectives and where should those metadata and data come from. Right? But once you work through that, creating them is pretty simple. It's a windy wake experience and broadly to create these change types.

And using them is even simpler, right? That's really just hitting, picking the right change steps and hitting a go button and, you know, please reach out if you want to kind of go the next step and automate the process and hook it up to your work management system. We do have APIs available and CLI plugins available that allow you to do these things programmatically, not to create them, but to use them.

Jenn (24:30.064)
Absolutely. And I think from a kind of a technical side from Prodly, as far as considerations, I think it's pretty much limited to you will need to have Prodly installed in your production org, as well as having Dev Hub enabled and an org shape defined. Is that correct?

Max Rudman (24:34.161)
you

Max Rudman (24:51.481)
Not exactly. Everything is correct except for the first part. You don't need to have it broadly installed in your production org. That's the beauty of our architecture. You can have it installed in any org. But yeah, you do need to have work shapes set up in your dev environment hub enabled in your production org. But Proudly doesn't need to be installed in the production org. You can drive this process from any org, in fact.

The best practice is to have a separate tooling org, the DevOps org, where you run broadly and just connect to all of your environments in your pipeline.

Jenn (25:34.69)
Excellent. Thank you, Max.

Prodly - Scott (25:37.824)
Yeah, it's great. All right. Well, I guess it's now time, if you want to show up your screen here, we'll do a little quick little demo again. We talked a lot more about it than I think what the demo will be, but hopefully, we'll give you a good representation of how to create those scratch orgs and change types. So Jen, over to you.

Max Rudman (25:43.513)
Thank

Jenn (26:08.072)
All right, so to get started with our demo today, I did want to walk through some of those setup steps. So of course, we mentioned having Dev Hub enabled in the org that you want to build this off of. Here we go.

Jenn (26:29.616)
So to enable Dev Hub, you do need to come into Salesforce Setup and then just search for Dev Hub. Mine is already enabled, so you don't see the option to enable it. Once it's enabled, I believe it cannot be disabled after that. So just be sure you want to enable Dev Hub before enabling it. And then from there, you can also come and search for Scratch Orgs, which will...

Allow us to specify an org shape. So you will need to specify an org shape here or rather an org ID. This org ID, you're essentially authorizing the org that you enter here to build scratch orgs off of this production org that you're setting it up in. And just note, this does have to be the 15-character org ID, not the 18-digit. So those are really just the preset up steps. And then once you have set that up, that's when you'll be able to

Create a scratch org from our UI. So you'll see the create scratch button from the environments page. Now when you come in here it's really straightforward, super simple, the wizard walks you through what you need to do. You give your scratch org some type of name, something that means something to you.

And then you can choose the source, of course, that you want to build the org off of. Back to the duration of the org that we mentioned earlier, you can set a custom duration if you'd like, or you can just go with seven or 30 days. The max, I believe, is 30. From there, you can also pick and choose which packages you want to pre-install in that org. You can unselect them all and just go in and pick and choose the ones you actually want to deploy, or rather install. And then you can actually drag and drop them.

If there's a specific order that you want them to be installed in or they need to be installed in, just be sure to drag and drop in the order you need. For the metadata piece, this is going to be working off of our metadata filters, which if you are already deploying metadata, you're probably already familiar with these filters. We do give you some out of the box, but you can always create your own. So you'll need to tell us what components you want us to include in there using a filter.

Jenn (28:34.072)
Of course, you also have the ability to roll that back if some of the metadata fails. So we can prevent, you can prevent us from going on to create the org if some of your metadata fails. And then of course, the data piece to seed your org, you're going to choose either a data set or deployment plan from the list here, one that you're already using Prodly with Prodly. And you also have the option to prevent the data piece if the metadata piece fails. So these would be the settings to create the org. And then you just go ahead and create

The Scratch org when you're ready. Once you hit create Scratch org, this will spin up a Scratch org environment, which you will see appear here. So you'll see it will appear like any other environment. It will be labeled with the Scratch org, of course. And then when you click into that org, you can access the org through the link if you're the one that set it up. And you can also see when that org is set to expire.

So this is how you would spin up a single scratch org. Now, when we're talking change types, change types are really allowing us to create kind of a template of that scratch org and to be able to quickly spin them up whenever you need them. So when you wanna work off of a change type, you can just come in here and choose your change type, but first, you need to create the change type. So you can hop to the page from here. I've already opened it up here. So change type, again, same very similar UI to what we just saw with the scratch org, pretty much the exact same.

Same thing, just give us the name, the source that you want to build it off of, duration, packages, metadata, and data. And then once you have your change type, like here for example, I have my cpq change type. I can also edit this if I ever need to or if I want to make changes to it. But you see I have some of those, like I have advanced approvals, billing, cpq in here, got my all major metadata types, and my full cpq deployment plan to go in there and fully push my cpq config. So I'm going.

To build a scratch org off of this change type. So I'll come in and choose my change type. Of course, I have a preview of what's in that change type to make sure that I'm choosing the correct change type. And then I'll come in here and give this a name and we will just hit create.

Jenn (30:48.352)
And in just a moment, you'll see the environment card being created. We will also, the user who creates it will also be receiving emails throughout the creation process, so you know where the process is at. Once the packages start getting installed, you'll be updated when they're successfully installed. If there are any issues, you'll receive an email as well. And then once you have your org, like I said, it's just like any other org in your environments page. You can run deployments to and from it. You can also, of course, go and enable

Version control in it as well if you need to. I think that's all I got for today.

Prodly - Scott (31:26.708)
Yeah, that's perfect. Thank you, Jen. That was a good visibility into Prodly and how it can work. Again, I think it's just the beginning stages of the broader process of what Max talked about, setting up what the future can be for the new, for your new process, and how to fully take advantage of using these. So, all right. Well, what's next? Well, as always,

is your customer success manager, Jen, and I. Please don't hesitate to reach out if you want more information. Of course, you already trust us for your complex data. Why not trust us for a whole lot more? And if you're viewing this as a prospect or want more information, you can reach out to me as well. We'll get you in touch and maybe get you a demo not only of the change types but of the whole.

The whole product as a whole. So, we have many, many of these videos that are already on our website. So hopefully take a look at the rest of those videos and there'll be more coming in the future. So, maybe we'll bring Max back on for a couple of more. So, I appreciate your time, and thanks Max for the insights and Jen as always until next time. We'll see you then.

Jenn (32:43.76)
Thank you. Bye.

‍