Today on the Salesforce Admins Podcast, we talk to Rohit Mehta, Senior Product Manager for Sandboxes and Scratch Orgs at Salesforce. Join us as we chat about how to think about sandboxes and scratch orgs and some tips for how to use them better.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Rohit Mehta.
We’ve talked a lot about why sandboxes are so important for admins over the years, but we’ve never really gotten into the nitty-gritty of it. That’s why for this episode, we thought we’d bring on the sandbox PM, Rohit, to talk through everything.
Rohit has been at Salesforce for a long time, first as a computer engineer and then later on the product side of things. In fact, he says, “a lot of the product that I manage nowadays I actually built, years ago.” Since he took over the team, there have been a lot of improvements to what sandboxes have to offer, including upgrades to speed and reliability, data masking, and partial sandboxes—and the future is looking even more exciting.
One big thing coming up is sandboxes for Hyperforce. If you’re not familiar, Hyperforce is a Salesforce deployment on public cloud infrastructure (like AWS). “One of the most common complaints that we get from customers is that their sandbox takes too long to create,” Rohit says, “but now with Hyperforce, we can produce sandboxes much much faster due to a newly-rearchitected design.”
They’re starting with Quick Clone for Dev and Dev Pro sandboxes coming up in Winter ’23, with an eye towards a GA release in Spring ’23 (forward-looking statement!). The Create operation will be coming along shortly after, so lots to look forward to. “People don’t often think about speed as a feature,” Rohit says, “but we make speed improvements on every release.” And the goal with Hyperforce is to be able to create sandboxes an order of magnitude faster than before. That’s 10x, for those of you playing along from home.
Rohit is also the product manager for scratch orgs, so we figured he’s perhaps the best person in the world to ask this question: what’s the difference between sandboxes and scratch orgs? Scratch org is a source-driven and disposable deployment of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with different features and preferences, and they only last 30 days. Sandboxes are copies of your Salesforce org that you can use for development, testing, and training, without compromising the data and applications in your production org.
Source-based development can really improve the speed that you’re able to deliver complex projects, so Rohit encourages every admin to give scratch orgs a closer look. While creating one through the CLI may seem complicated, there are a lot of resources out there to help you make it happen, and new declarative options are on the way.
Mike Gerholdt: Welcome to the Salesforce Admins Podcast where we talk about product, community, and career to help you become an awesome admin. And this week we’re talking with Rohit Mehta, who is the senior director of product management for Sandboxes at Salesforce.
Now, let me tell you how much fun this episode was, because you’ll learn, I’m just going to give away burying the lead here. You’ll learn that Mike finds out that Rohit is also the product manager for Scratch Orgs. But in all seriousness, this episode Rohit gives me the most useful description to understand sandboxes and cratch orgs. And a piece of wisdom that I’m going to let you find that I will call out in the wrap up. But for now, this is a fun podcast. Let’s go ahead and get Rohit on the pod.
So Rohit, welcome to the podcast.
Rohit Mehta: Hey Mike, thanks for having me here.
Mike Gerholdt: Yeah, well I realize looking through all of the content that we’ve created over, gosh, how many years the podcast has been on, I don’t think we’ve talked about sandboxes nearly enough. And as admins, the one thing we always preach about everything that you should be doing is of course do it in a sandbox first. So I feel like having you on the pod is long overdue. But before we get in and talk about sandboxes, let’s talk a little bit about you. Rohit, how did you get to Salesforce as a product manager?
Rohit Mehta: Hey, thanks Mike for that question. So I have been at Salesforce for quite some time now. I’ve spent 11 years, almost 11 years at Salesforce. My journey began as an engineer. I went to school in the Midwest for my computer engineering degree. I went to University of Illinois, go Illini. And right after college, I got a job as a computer engineer in Chicago. So that’s where I spent my initial years before coming over to Salesforce. I joined Salesforce as an engineer as well and spent a lot of time on the Sandbox product. So a lot of the product that I manage nowadays was actually built by me years ago. At some point I decided I wanted to get a bit more into the business side of things, interact with customers more, sort of see how the whole thing is built, the full pie, so to speak, and made the transition to product management.
Mike Gerholdt: Wow. We don’t talk about it a lot, but I think you might be the first Big 10 guest on I’ve had. Our team’s actually played football against each other and you guys won. Holy cow.
Rohit Mehta: We haven’t been the best in football, but I think in the recent years the team has improved.
Mike Gerholdt: Yeah, well we just have mediocre here in Iowa, but people didn’t come to listen to Big 10 Football Talk. Just found that kind of interesting because it never comes up. So tell me a little bit about some of the things that you’ve worked on for sandboxes, because I feel like I don’t… I’m sitting here thinking of like, oh, that’s a really cool sandbox feature.
Rohit Mehta: So sandboxes are quite an old product at Salesforce. They’ve been here for quite some time, and the product has evolved significantly ever since I started the team. There have been a new type of sandbox that was created, partial sandboxes, which again have been around for a few years. There have been a lot of incremental changes made to improve the speed and reliability of sandboxes. There’s been products such as Data Mask that have been built to enhance your experience in sandboxes. And then most recently there are a bunch of initiatives that I’m working on that are going to significantly improve the product line and I’m very, very excited about them.
Mike Gerholdt: But Safe Harbor, we can’t talk about them?
Rohit Mehta: Well, Safe Harbor, I can speak a little to them. But Safe Harbors.
Mike Gerholdt: Oh, please do. We always love to hear that.
Rohit Mehta: Okay, well, Safe Harbor statement, just as we like to apply those in our Dreamforce presentations and other presentations where we talk about forward-looking statements and forward-looking products. But a couple of initiatives that I’m most excited about are sandboxes on Hyperforce, and another one around selective sandbox access. So let me speak a little to each of them.
Mike Gerholdt: Yeah.
Rohit Mehta: So sandboxes on Hyperforce. For those of you who aren’t familiar with Hyperforce, Hyperforce is Salesforce running on public cloud infrastructure such as Amazon’s AWS. This helps Salesforce expand its global footprint by delivering services in different regions. It helps provide data residency for customers that need data to be geo-located where the company is located. It also helps Salesforce step into the flexibility and the scale that AWS provides. Now, sandboxes are a product that could benefit from the scale, and that’s exactly what we’ve done here. One of the most common complaints that we get from customers is that their sandbox takes too long to create, especially if you’re talking about a full sandbox. A full sandbox is one which, as you know copies over all the data from the production org and produces a near replica of the production org. Now, if the production org is large gigabytes or terabytes in size, that can take a long time to copy.
Mike Gerholdt: Yeah.
Rohit Mehta: Well, now with Hyperforce, we are able to produce sandboxes much, much faster due to a newly rearchitected design. So if your production works moves to Hyperforce, which is a prerequisite for this feature, sandboxes can be created roughly an order of magnitude faster. In our initial testing, we have seen in performance improvements of 2X to 15X. Now that’s a pretty broad range and depending on the production org, the size and the complexity of the customizations, the performance improvements will vary. But our goal is to get copies created and order of magnitude as in 10X faster. So that’s one of the features, that’s around Hyperforce. We have two sort of sub… The way we described the feature of Faster Sandboxes is via Quick Clone and a Quick Create. So as you know today, you can create a sandbox, which is a copy of the production org, or you can take an existing sandbox, make customizations in it, and then clone that sandbox.
That operation of creating from production org is made faster, and that’s being called Quick Create. The operation to clone an existing Sandbox has also made faster, and that’s being called as Quick Clone. Now we are starting off with our launch and our rollout of the feature with Quick Clone. That’s that just helps us build the right scale, help roll this out in a fashion, which is going to help us get all our bugs out before we can roll this out to all sandboxes. And so the staggered fashion just helps us with the overall testability and reliability of the product. We are starting with Quick Clone release for Dev and Dev Pro Sandboxes specifically in the Winter ’23 release. The Winter ’23 release is the one that’s live right now. And we are just wrapping up a few things before we can roll out a Quick Clone for those two sandbox types for customers that are in Hyperforce.
And then forward looking statement, we are going to be launching Quick Clone for partial and full sandboxes as GA in the Spring ’23 release, which gets rolled out in February 2023. At that same time, we are also going to be launching a pilot for that create operation, Quick Create is how I called it for full sandboxes so that we can test it out, get customer feedback and get it ready for GA in a subsequent release. So the pilot will start in Spring ’23 as well. So all of these capabilities running on Hyperforce, they require that the customer’s production org is on Hyperforce. That’s how we can tap into that new architecture that we build to speed up copies.
Mike Gerholdt: Yeah, I never thought about the fact of how fast it takes to spin up a sandbox is actually a feature. I just figured that was just part of the process, but the ability to segment and I remember seeing some of these different Sandbox version types come out and think, oh wow. But it was always within my project planning of a week out or so to have the sandboxes ready so that by the time the project started, we weren’t ready for Sandbox. We were ready to go and we weren’t waiting on sandboxes to be created. So that’s interesting.
Rohit Mehta: And Mike, you’re right. People often don’t think about speed as a feature and we make speed improvements on every release. We make this consistently release over release and the speed improvements help our customers. But those changes and those improvements are sometimes not noticeable because they’re incremental in nature. And so we never even talk about them publicly and customers may or may not notice them.
Mike Gerholdt: Right.
Rohit Mehta: With Quick Create and Quick Clone, the speed improvements are significant. They are, as I mentioned, at least 2X faster and we have a goal of achieving 10X or better. And so for such a big improvement, we think it’s important that customers are aware that we are delivering this. Customers are aware of the prerequisites for getting access to these features, which is being on Hyperforce. And so we are speaking about this as a feature.
Mike Gerholdt: Now thinking through, listening to you, tell me about all this. One thing that I’m thinking of, maybe this seems like a naive question, but I’m going to ask it anyway because I’m curious. You have to be hyper plugged in to all of the features that are coming to the platform, right? Because at any one point in time that’s going to impact your product because somebody’s going to spin up a sandbox and want to use X new feature. So do you just constantly have a line of product managers outside your office being like, we need to talk about my product and how it works with Sandboxes?
Rohit Mehta: Not quite.
Mike Gerholdt: Not yet.
Rohit Mehta: Not yet. That’s right. Well, so the way sandboxes are architected is that anytime a new feature is added to the production org, it becomes included in the sandbox by default. So teams within Salesforce usually don’t need to do any additional work to support sandboxes. They may have to do some testing to make sure that the feature works correctly in the sandbox, but development work wise, it’s often minimal.
Mike Gerholdt: That’s what I thought you would say, but in my mind I was like, man, you could be the go-to person.
Rohit Mehta: Well, yeah, although I would love to spend more time with customers and there’s only so much I can do in a day.
Mike Gerholdt: Yeah. Now I feel like tangentially to you, there’s also Scratch Orgs. So how closely do you work with the product manager for Scratch Orgs?
Rohit Mehta: So Mike, I am the product manager for Scratch Orgs.
Mike Gerholdt: Oh.
Rohit Mehta: I manage both the environments used for development on the product.
Mike Gerholdt: So you work really close with that product manager, that’s what you’re saying?
Rohit Mehta: Yeah, I know a guy.
Mike Gerholdt: Every day.
Rohit Mehta: That’s right. Exactly.
Mike Gerholdt: Every day.
Rohit Mehta: Every day, every day. 24/7.
Mike Gerholdt: Tell me how admin should think about Scratch Orgs versus sandboxes.
Rohit Mehta: Yeah, that’s a great question. So people often ask me when they meet me at Dreamforce or even in some of our online communities, when should they use a dev sandbox, and when should they use a scratch org? Now the key difference here is that a dev sandbox is a copy of the production orgs metadata and it brings over all the metadata, all the customizations, but no data. A dev sandbox also does not expire. So for as long as you continue using it, the sandbox stays active. Scratch Orgs, on the other hand, are meant to be ephemeral environments used specifically for source driven development. So source driven development is a modern way of building changes and one that Salesforce has adopted over the last five or six years. And so in source driven development, the key difference is that the source of truth of the metadata is not the production org and the metadata doesn’t reside in the production org, but rather in an externalized version control system.
An example of that would be GitHub. The goal then becomes populating a development environment with this externalized source rather than copying it from another org such as the production org. So scratch orgs are source driven, which means they’re populated from a version controlled system, they’re empty otherwise when they’re created. They’re also [inaudible] FMRL. They only have a max lifespan of 30 days. And this is again, to enforce best practices that an org is not supposed to be the long term home of any customizations. It’s only meant for developing those customizations and testing those customizations. The changes then have to be synced back into the source control system. So there’s sort of a big difference there between sandboxes and scratch orgs and how they’re meant to be used. Scratch orgs work wonderfully for package based development. Packages in Salesforce land are these bundles of code that are built and deployed into production orgs, and they’re built using [inaudible].
So they’re built from source controlled system. And so Scratch orgs work wonderfully well for that type of development because it requires that the source is in version controlled system. If a customer doesn’t choose to use version controlled system, which again, in my opinion is not a great thing. They can use devs and boxes, in which case they would have all of the metadata copied from the production org into the sandbox. Admins might look at scratch orgs and see the tooling that’s used for building them, such as the command line interface or the CLI and feel a bit apprehensive about the technical nature of the tooling.
However, number one, the CLI is actually quite easy to use and Salesforce has put in a lot of thought and effort into improving its usability. So our documentation, our videos, and the support from our community is great on how to quickly adopt the CLI. And then secondly, we are working on building more declarative experiences to help use some of our tooling that was geared towards our pro coders. So things like using working control system, things like using the CLI, all of these tooling we are making more accessible to admins by products such as DevOps Center and products such as Code Builder. These tools provide a declarative interface to the same capabilities that the CLI and the version control system have.
Mike Gerholdt: So that is probably the best explanation of scratch orgs versus sandboxes that I have heard since I’ve been at Salesforce.
Rohit Mehta: That’s great.
Mike Gerholdt: I totally get it now. I, for the longest time had a hard time compartmentalizing scratch orgs and sandboxes and understanding. I’m newish but I didn’t come from a code background. I don’t come from that kind of line of thinking of that you have a repository for all of your changes and customizations. To me, the world I grew up in was your production org was that, right? It was what was built and that was your explanation. So help me understand that. I have to thank you for that because I’ve been trying to wrap my head around it for a long time.
Rohit Mehta: And Mike, just to be clear, that model still works. Salesforce still supports it and we have no plans to not support it in the future. So sandboxes are here to stay and then developers and admins can use sandboxes. However, as teams evolve and the complexity of projects evolve and the need to deliver faster increases, it is imperative for teams to adopt or at least look at using version control systems and the tooling that we have built with Scratch orgs, the CLI, the packaging, the help with that source driven development approach.
Mike Gerholdt: Yeah, no, that’s the part that I love, that I finally understand now is that no matter how your development lifecycle works, there’s a way to do it and follow a best practice. You can use sandboxes to production or you can use a GitHub repository and scratch orgs and go that route and totally… Yeah, that’s so cool. It makes sense to me now and I’m glad we have it.
Rohit Mehta: I’m glad you get it.
Mike Gerholdt: It just takes a while. Sometimes the coffee has to really kick in and makes sure everything, it makes sense. But that’s really neat. Outside of building really cool things for admins and developers with sandboxes and scratch orgs, I’ve had guests, product managers, I’d love to know what their hobby is because I think it’s fun. It was fun when I was a customer to know what people’s hobbies were. I remember talking to some PMs that loved to play board games. We had one product manager on that in their spare time smelt metal and poured them into little figurines. I’d be curious if you have any interesting hobbies you’d love to share?
Rohit Mehta: Yeah, as you were mentioning that, I was thinking, I wish I had a hobby as cool as smelting-
Mike Gerholdt: A really cool hobby, like smelting metal?
Rohit Mehta: Yeah, that sounds so cool.
Mike Gerholdt: Yeah. It does, until you burn yourself and then I think I would be done.
Rohit Mehta: That’s true. All it takes is one accident. Yeah, that’s true. Yeah, so I do like to stay a very active life and I do like to run. I’m in Chicago currently, which while we are taping this, it’s 30 degrees outside or something like that. So it’s not-
Mike Gerholdt: Heat wave. It’s hot.
Rohit Mehta: 30 Fahrenheit, not Celsius, but it’s not the most conducive for running at the moment. But I do like to run. And then I also like to try new foods and eat. So I guess that counterbalances each other.
Mike Gerholdt: Well you got to do one if you’re going to do the other.
Rohit Mehta: Yeah, absolutely. You can’t do one without the other otherwise. Yeah, I wouldn’t be fitting into my clothes soon.
Mike Gerholdt: Right. Yeah. So Chicago has a really robust food scene. I mean, I would equate it easily, easily with New York. I think people undersell Chicago, they just assume it’s all deep dish pizza, but there’s a lot of really, really nice high-end restaurants in Chicago as well. So you can kind of balance what you’re looking for. Obviously, you don’t want seafood, but terms of a good steak, I would put it on par with steaks I’ve had in New York. So food scene Chicago is a good place to be.
Rohit Mehta: Oh yeah. It’s definitely a very diverse place for trying out different foods.
Mike Gerholdt: Absolutely. Well, Rohit, it was a pleasure having you on the podcast and explaining sandboxes and scratch orgs and a lot of the features you’re working on to everyone. So I want to thank you for popping over and at least helping me. If anything, this episode helped me.
Rohit Mehta: I’m so glad you had me on the podcast, Mike. This was wonderful. I take every opportunity I can to connect with our admins and developers and so hopefully this is another fun way for them to get to learn more about sandboxes.
Mike Gerholdt: So it was great to connect with a fellow Midwesterner. Don’t get many of those on. And we always share the weather in common here in the Midwest. It’s one of the few things we talked about. But anyway, few things that I pulled out of there in case you didn’t notice. I just assumed there was probably a different product manager for scratch orgs and sandboxes, one and the same. So that was fun. You just get to watch Mike or listen to Mike put his foot in his mouth. But the one thing that I think Rohit called out that was really interesting that I’m glad he said, speed is a feature. And boy, that was kind of interesting talking through the different ways that we can spin up different sandboxes. So I hope you enjoyed the pod, I did. Even though his finding a line, I beat my Hawkeyes this year.
So be it. That’s what happens sometimes in BIG 10 football. But yeah, this is really fun. I hope you enjoyed the description of how Rohit explained scratch orgs and sandboxes. I know it was something that I’ve always kind of been struggling with as I worked to understand the universe of computing and coding and everything that goes into our jobs. So that was a bit of a moment of clarity for me. But if you want to learn more about all things admin, please go to admin.salesforce.com to find more resources, including any of the links that we mentioned in this episode, as well as a full transcript.
Now you can also stay up to date with us on social. We are at @SalesforceAdmns, no, I on Twitter, of course. My co-host Gillian is on Twitter. She is at @GillianKBruce. And if you want to follow me on Twitter, I am @MikeGerholdt. So with that, stay safe, stay awesome, stay spinning up those sandboxes and stay tuned for the next episode. We’ll see you in the cloud.
Today on the Salesforce Admins Podcast, we talk to Lizz Hellinga, Consultant and Salesforce MVP. Join us as we chat about why product management principles in Salesforce are crucial if you want to take advantage of new AI tools. You should subscribe for the full episode, but here are a few takeaways from our conversation […]
Today on the Salesforce Admins Podcast, we talk to Tom Leddy, the Product Director of Decision Guides at Salesforce. Join us as we chat about decision making in the age of AI and why cleaning up your data is more important than ever. You should subscribe for the full episode, but here are a few […]
Today on the Salesforce Admins Podcast, we talk to Lisa Tulchin, Senior Curriculum Developer at Salesforce. Join us as we chat about choosing the learning path that fits your learning style and strategies for training your users. You should subscribe for the full episode, but here are a few takeaways from our conversation with Lisa […]
