Liz Moorehead
This week, weβre getting into a topic weβve weirdly never covered before: HubSpot sandbox environments. And I have to give a shoutout to Chris Carolan for suggesting this one, because it sparked a way more nuanced and necessary conversation than any of us expected.
If youβre like a lot of teams, youβve either:
a) heard of sandboxes but have no idea what theyβre for,
b) think you donβt need one because youβre βjust testing a few workflows,β
or c) realized too late you probably shouldβve used one before things broke.
π Go Deeper: Yes, the HubSpot Is a CRM... for All Teams, Not Just Sales
So we slowed things down to answer the real questions: What even is a HubSpot sandbox environment? Whatβs the difference between a standard and a developer sandbox? When do you actually need one? And what are the real costs of skipping it. Whether thatβs because of speed, lack of awareness, or just hoping nothing explodes when you hit publish?
And look, Iβll admit it: This conversation gets into some real operational therapy. Weβre not just talking about tech. Weβre talking about how sandboxes expose deeper problems with process, misalignment, and fear of friction. Because the tool itself is just a container. Itβs how you use it that either supports your businessβor makes you realize just how little visibility you have into how things actually work across your org.
What We Cover
-
What a HubSpot Sandbox Actually Is: We break down the difference between standard and developer sandboxes, what gets cloned (and what doesnβt), and why this tool isnβt just for enterprise-size teams.
-
Why Most Teams Donβt Use Sandboxes Enough: Max lays out the three biggest reasons teams avoid sandboxes: time, fear of disruption, and sheer lack of awareness. We talk through each one and why none of them are great excuses.
-
The Risk of Testing in Production: Weβve all been there. Making edits in a live environment, crossing your fingers, and hoping no one notices the chaos. We unpack the real business risks of skipping sandbox environments.
-
How Sandboxes Surface Deeper Organizational Problems: This episode isnβt just about the toolβitβs about what your resistance to using one might be telling you. Chad brings receipts on how sandboxes expose misalignment, lack of process ownership, and fear of visibility.
-
Developer Sandboxes vs. Standard Sandboxes: I push for clarity here. What exactly is different between the two, and how should technical and non-technical teams approach them differently?
-
Why Sandboxes Should Be Part of Your Enablement Strategy: Sandboxes arenβt just for building. Theyβre for training. George and Chad explain how sandboxes can be used to create safer learning environments for new hires, new processes, and operational maturity.
-
When Sandboxes Arenβt Worth the Overhead: We also acknowledge there are times when creating a sandbox isnβt the move. We talk through what those edge cases look like and how to evaluate cost vs. control.
-
What This Means for How You Operate: We wrap with a bigger question: If your team doesnβt feel safe enough (or aligned enough) to even test things before launch, what does that say about your operational culture?
And so much more ...
Episode Transcript
Max Cohen: I feel so activated right now, George.
George B. Thomas: And educated.
Liz Moorehead: Me too
Max Cohen: educated.
George B. Thomas: Yeah.
Max Cohen: I'm about to unite our superpowers together.
George B. Thomas: Oh, hibernated. Ated. Wow.
Max Cohen: Dude, you know what I got into last
George B. Thomas: Is this, first of all, is this G rated? PG rated?
Liz Moorehead: Adjudicated is a legal term.
George B. Thomas: No. I mean, max. Max said, do you know what I got into Right. Do.
Max Cohen: Yeah.
George B. Thomas: So I was asking is that, is that pg or G rated?
Max Cohen: It's rated.
George B. Thomas: Oh,
Liz Moorehead: Oh,
Chad Hohn: It is rated a level.
Liz Moorehead: that is an answer. Thank you, max.
George B. Thomas: It
Max Cohen: Mm-hmm. That's an answer. Um, I'm getting into a little bit of a game dev.
George B. Thomas: Oh
Chad Hohn: Nice.
Max Cohen: a platform called Godo. Godo.
George B. Thomas: it called?
Max Cohen: It's French, it's G-O-D-O-T. Go Godo,
Chad Hohn: Yeah.
Max Cohen: duh.
George B. Thomas: I got some tissues for that.
Max Cohen: Yeah.
Chad Hohn: Oh.
Max Cohen: I haven't learned how to make tissues yet, but I did make a table in boxes and I put the box on the
George B. Thomas: So is this like, kind of like a, um, is it like really high definition or is it more like the eight pixel type? Uh,
Max Cohen: It's 3D. It's three DII made some low poly textures, if that's
George B. Thomas: Oh wow.
Max Cohen: up in, I do be up in that block bench, you know what I mean? Painting some pixels, 16 bits. Yeah. Yeah. Yeah,
George B. Thomas: I'm not sure how this relates to sandboxes in HubSpot at all, but Hey.
Max Cohen: it's like I'm playing in a sandbox dog.
Chad Hohn: Yeah.
George B. Thomas: You made boxes
Chad Hohn: he made a box.
Max Cohen: Well, it's like I got my own virtual sandbox I'm playing in, is what I'm saying.
Liz Moorehead: Oh.
George B. Thomas: Wow.
Liz Moorehead: I did absolutely no sandboxing, no sandboxing this weekend. I have been binge watching Game of Thrones, and I had a really good omelet. So I'm looking to get my fill of sandboxes this morning. So George, I actually wanna tee you up for today's conversation if we're ready to dig into it.
So you got a ping from one of our favorite friends of the pod, Chris Carolann, who was asking for this episode. Talk to me about what he was asking for.
George B. Thomas: We were talking about customer platform updates, and I do believe that we ran across a, uh, product update that is the new standard sandbox with improved production, uh, metadata and deploy to production supported assets. That is the longest name of an update ever, uh, to a HubSpot product. Um, we were going over that and Chris referenced like, Hey, you know, it'd be great to have Chad.
He literally named Chad, uh, wax nerdy. 'cause Chris really loves when, um, Chad wax nerdy on things on the show. We should see if Chad can wax, uh, nerdy and Max can wax nerdy on sandboxes. And I think that that would be a useful episode. I, I, and I set. Chris, I think you're right because, you know, one thing that I don't do a lot of in HubSpot over the last, like, you know, eons since I'm the grandpa of, of inbound and grandpa of HubSpot sandboxes, like most of my, uh, clients are small to medium sized businesses.
They have like marketing or sales pro or less. And so, uh, which by the way, we'll get to why that's important to why I don't really do sandboxes a lot. Here we are. We're having an episode. We're talking about sandboxes. If you, if you've ever been curious, if you should have a sandbox environment, uh, what a sandbox environment is, maybe some of the cool things that Chad or Max have done with sandboxes, well then buckle up.
Uh, 'cause we're playing in the sand today. Now also, my, uh, beginning joke might make a little more sense, or us rambling about boxes might make a little more sense too. Thank
Chad Hohn: got there. We
Liz Moorehead: We got there, guys. We got there. Now, I personally am excited about this episode because again, I play in very specific parts of HubSpot and I don't often get to learn or hear about these more technical areas. So let's, let's start with that kind of obvious question, right? Like, I've heard of sandbox environments in HubSpot.
Sandbox environments are not necessarily a new HubSpot specific concept, but when we're talking about HubSpot Sandbox for today's conversation, what specifically are we talking about it Take the nerd and make it user accessible. What are we talking about?
Max Cohen: So like imagine if you could take your HubSpot account and duplicate it so you could go play with it and test stuff without breaking the real stuff.
George B. Thomas: Yeah, yeah. Before Chad goes, I, I actually, I'll be completely honest with everybody listening to this. I took this conversation and these questions to my clone, and I asked my clone, uh, what the heck is a HubSpot sandbox? And my clone said. The HubSpot Sandbox is like your personal testing laboratory, uh, max.
That's literally what you just said, uh, inside of HubSpot. It's a safe, isolated environment where you can experiment, test, and refine changes without messing up your live customer facing data. Think of it as a, I love this part, by the way. Think of it as a practice field. Uh, one of the things we love to do is we can go down to South Carolina, we can watch, uh, the Panthers practice.
Before they actually hit the big, so, so it says, think of it as a practice field where you can try out new plays before taking them to the big game. I was like, that's a pretty cool overview. That's a cool overview. Chad, where, where does your brain go?
Chad Hohn: Yeah, well, just, uh, in general, like to break it down when it comes to development as a whole, like, if you're gonna be developing anything, which let's be real. Like why, you know, people may call, oh, hey, we're CRM super admins, or whatever. But at the end of the day, what you're doing is you're building, you're developing some sort of process or some sort of new thing for somebody to use.
A lot of times when you're adding any kind of functionality or feature to HubSpot. Just in general, software development, typically you want to have a few environments, actually. You want to have a production environment, you want to have a test environment, and you want to have a dev environment for the developers to go play around in.
Now, I used to work at a company we used to call our dev environment the trash can, and then when we'd want to go in and do just a little bit of testing on a new build, they'd be like, yeah, get outta my trash can, you know, like. I'd like want to go in early to see new features before they were ready. Like, yeah, I'm a trash can.
It's not working, you know, and then they'd like push it up to test. Once it was ready for somebody to like make sure that it's not really gonna mess up everybody's world right now, we don't have that here in HubSpot Sandbox. We have two separate isolated environments. But what we do have is the ability to duplicate that live environment into what I would probably call a test environment.
Right.
Max Cohen: Yeah, and I think also it's important to kind of like explain the difference between this and other ways that you can just kind of like play around with stuff. So like if you just wanna, if like you're someone who just wants to like. Futz around. With HubSpot, you can go create a developer account and create what's called a test account, which is essentially a, uh, a blank slate, everything enterprise HubSpot account.
The only difference is you can't send emails to people. Right. So it renders, it functionally useless for anyone who wants to like, do anything real with it. Yeah. Um, so that's a developer sandbox that, or, or sorry, a test portal. We don't wanna call those sandboxes. Sandbox specifically, the big difference is that it's gonna duplicate the way that your portal's already set up.
So like imagine your layouts, your records, your custom objects, your properties, and then you could even bring in, I think, what is it now, like
Chad Hohn: 5,000
Max Cohen: of your most recent records or
Chad Hohn: and their associated objects or something like that.
Max Cohen: exactly. And you can bring those in. So you can play with like real data. Right. Which is great, but you're not gonna screw up the original stuff.
So like. This is really, really good if you want to test a new workflow that you build so you can see how it interacts with like stuff, or if you wanna, like, if you're doing any sort of like big data restructuring exercise, right? This is a great place to do it because you can kind of see how it'll all work without messing up your data structure in your regular portal.
Right? Um, so there's a million reasons why you might wanna use the sandbox.
George B. Thomas: And I think
Liz Moorehead: George, I have a clear.
George B. Thomas: for one second. Oh, yep. Yeah. So let me jump in for one second because one of the things too is 'cause uh, max you did say development sandbox and then also what you guys kind of like backed up and then, uh, alluded to was a standard sandbox. Like right now, if you, and it may be because I have this beta on, or it may have been that way historically.
Again, remember I don't do a lot with sandboxes, but I just want everybody to know the experience. Now, if you go in and you create a new sandbox, you actually have the ability to pick one or the other. You can pick a standard sandbox. Which again, is kind of that extensive copy of production idea for like the robust testing.
It's the, you know, the 5,000 contacts, the production objects, the forms, the workflows, the emails, all of that. Or there is the Development Sandbox, which is like a minimal copy of production, uh, for like rapid testing. So this is like when you're gonna just test proof concepts, test proof, custom cards, things like that.
Go ahead,
Max Cohen: but let me clarify something. I was referring to developer test accounts, which are a separate idea. So like, but that's a good distinction too, right? In, in when you make a sand, like when you have an enterprise HubSpot account, you can make a sandbox and either have it be a standard or a developer sandbox.
And like a developer sandbox is great if you're trying to like test an integration or some APIs or something, like whatever stuff that you're trying to
Chad Hohn: you're trying to build a UIE right?
Max Cohen: Something like that. Yeah. Some sort of extension. Right. Um, but you have to have an enterprise account in order to build those, a developer test account.
Any random Joe Schmo can go get a HubSpot developer account and spit up test portals. Right. So like bucket that outside of this conversation for anybody listening, right. Like. I know there's like a lot of people like, oh, I don't have enterprise, I can't do a, I can't do a sandbox. Nothing's stopping you from going and building, like proof of concept stuff in a developer test
Chad Hohn: a hundred percent.
Max Cohen: Literally nothing. Right? You just won't, it just won't copy anything from your portal. 'cause it's a disconnected idea completely from like, you know, being related to your portal in any way with shape or
George B. Thomas: one, one thing I wanna double click on before I then shut up and let Liz, uh, continue us down the path that we're supposed to go down. 'cause I find this very interesting as, as somebody who has been helping train humans in HubSpot for years. Know that there are portals that have like test dash training for like forms and this, that, and the other thing that have to like go back and clean up.
Um, if you have the enterprise version and can't do a sandbox, one of the things that they have as a bullet point is like, train new users and explore features and tools. In other words, it could become the trash can of training. Like you could have a do a development sandbox, but it be your training sandbox where that's where you go and just train people in and all the stuff could be littered around it and it not impact like your actual HubSpot portal where you're day in, day out and people are like, why is this test dash training workflow in here?
Anyway, I'll shut up.
Liz Moorehead: So I only had one clarifying question before we moved on. 'cause George, I, you and I have done a lot of work together in HubSpot, is the sandbox environment we're talking about different from content staging.
George B. Thomas: Oh yeah, yeah, yeah, yeah. Good. Good question. So, completely different. 'cause content staging is part of like CMS or what is now content hub. If you wanna deploy website pages, landing pages, um, but be able to work on pages that are already live, make adjustments without anybody seeing them, but be able to have internal teams preview them and then push those pages live to like the same URL.
Um, that's what content staging is for. Very, very much just like content driven. By the way, if not, why we're here. But I wish you could actually do content stage blogs. But again, totally different conversation. HubSpot development team, hopefully you're listening to this, or somebody that knows the development team, who knows.
Maybe your mom's listening to this and they'll pass it on to you. But, uh, completely different than like a sandbox environment.
Liz Moorehead: Hi, mom.
Chad Hohn: that's like, uh, the content sandbox
George B. Thomas: Yeah. Basic. But I love, I love
Chad Hohn: like contest test probably, but Or pre-prod maybe. Maybe you would call it.
Liz Moorehead: Perfect. Alright, so let's throw this out there guys. What has changed with HubSpot Sandbox that we're excited about? What's the 4 1 1? What's the scoop?
Max Cohen: mm Well,
Chad Hohn: so they had Legacy Sandbox before, right? Um, and that's what they're called now. So if you have an older style sandbox, it's referred to now as a Legacy Sandbox, and then they have a new version of the Standard Sandbox, which essentially does a one-time import of your current HubSpot account. Um, but.
There is a bit of a distinction between the old and the new, right? The old sandbox, it could continually get refreshed, like the legacy one, um, where you could update it with whatever the current structure of your current production portal is. Now, uh, that feature has not been added to the new standard Sandbox, but they added a big one that people have been wanting for a long time, and this is killer for anybody who is.
A standard, um, like is managing one portal, like if you're a HubSpot super admin of one portal, this is like pretty, pretty epic, uh, because you don't have to pay for extra tools to solve some of these problems. And what it allows you to do is basically reverse sync, or they call it a deploy to production from your sandbox.
And it supports like. Five things right now. Right now, it supports the ability to like basically clone your portal, uh, add forms, lists, marketing emails, objects and property structures, and then workflows that involve any of those things. Um, I don't know for certain though. I don't believe it'll pull up any workflow.
Like if you put custom code in the workflow, it might not pull it over or if you put, you know, so there's a couple things that it still won't do, um, as far as reverse sync and those are the main things that are supportive. But when you're talking about like, okay, well. What I'm gonna do is create an integration like, or add a new feature, right?
Like I was working with a company and we added a contract management system, rad ai. Um, and so we were doing this contract management system and I was able to install the integration, add additional properties. Test the whole thing in sandbox and push all of those property changes back up to production, right?
Uh, and all of the, the, there was no new objects, but if there was a new object, it would do it. Property groups. It didn't manipulate the, um, user interface unfortunately. So that's also something that it still doesn't do. But, um, and you know, we can maybe double click on that later when we're going into some more of Liz's questions.
But it's, it's amazing now that at least at minimum you have a baseline and this is the, the worst this feature's ever gonna be, as we often say. Right. And they're only gonna be adding more and they're looking for feedback on. You know what, what's missing? Right? Well, what's missing is for me, you know, user interface, right?
Uh, update the user interface along with it. 'cause often you want to build a good user experience, not just, oh, I'm gonna put the bits and bobs in the back end, and then they'll all figure it out and production, right? You're gonna have to redo whatever you did over in Sandbox, in production, right?
Max Cohen: Yeah, and also like a little bit of historical context here too, like sandboxes have been around for a while, but they've never had the ability to push stuff back into the main production portal,
Chad Hohn: Yeah. And that's what a lot of big enterprise CRMs often have. Like, you know, if you get Dynamics 365, I mean, you have like, I think you have because it was made by Microsoft, right? So they have like three layers. Like you could do the whole dev test prod thing that I described. Basically in Dynamics, but also Dynamics is a giant beast of a system that's like, I basically have to be a developer to use it.
Max Cohen: Yeah. Now 70 important to note as of the day we're recording. This is August 18th, or no, not 18th, 11th.
George B. Thomas: Leah 11th, man, don't do
Max Cohen: Yeah.
George B. Thomas: us. Come
Max Cohen: I don't know why I did that. It is August 11th, right? Um. The way the deploy, so the deployed production stuff is in beta, right? And it, it's interesting because the limitations around it, um, are that you can only deploy back net new stuff you've created.
It doesn't let you edit existing assets, which is a little bit goofy, but again. Worst it's ever gonna be right now. Right. The logical first step to any of this is recreating net new stuff. Right. Editing stuff is world's more complicated. Right. Um, so keep that in mind, depending on when you're listening to this episode, is that like the, the deployed production feature is very new Right.
And it's half baked at the moment,
George B. Thomas: Well, and I think, I think this is where I jump in and say, listen, we're talking about a public beta. It is a beta version. So when Chad and Max say it's half baked or it's the worst it'll ever be, it's because it's a beta that, um, once it goes live, I'm sure a lot of the things that we're talking about, you know, maybe the product team will actually like tune in and check out this episode.
Uh, but a lot of the things that we're talking about might actually just be in the actual, uh, new sandboxes once they deploy the live version. Because smart humans like Chad Max and others out there, maybe even listening to this podcast are like leveraging it, using it. Second thing I want to throw out there is, um, it is right now for, um, anybody who signs up for the beta, but then also it's enterprise customer platform, content, enterprise marketing, enterprise ops, enterprise sales enterprise or service enterprise.
If you have any of those enterprises. You can turn on, uh, the sandbox feature that we're talking about here. Here's a question that I'm gonna ask, uh, and again, kind of going off the rails for a second, but when you guys talk about this deploy wizard, if it got smarter, 'cause it might not be now, but let me ask you a question 'cause my brain went there.
Do, are we entering a world where if you have an enterprise, uh, set up in HubSpot and you've got a sandbox. Marketing and people should actually maybe even be working. Like for instance, if I was gonna create an email, do I create the email in the sandbox and then deploy it to the real one and then send it from there?
Or is that overkill? Like you were talking more like nerdy stuff.
Max Cohen: Yeah, complete overkill. I mean, 'cause like that's the thing, you shouldn't be afraid to build stuff in your main portal. It's more so I would say, um, untested. Fundamental structural changes to the way your portal operates. You should, test drive it in the, in the, in the sandbox first. Right?
Um, you don't want to be spinning up a sandbox to go build an email. Just to push it into the, into the, the main portal, right? Like you can still draft like that doesn't, to me
Chad Hohn: Yeah. And preview send and all that. Mm-hmm. Yeah. Yeah, you have all the functions with that. If you were like, I mean, if you really needed to do something, like, you know, one of the things they push back is lists, right? And so if you had like property structure changes that you need to make to make your data clean. It may be worth attempting to build all of the lists that would let you segment all of your customers after all of those net new properties were changed, or something along those lines so that you could really understand your segmentation and. Unfortunately, reports don't push back. But that would be a nice thing too, is like, you know, now you can make your reports and it all works, and your lists validate everything.
Then you can push that all back up to production. Now at least you can push the lists and the, you know, stuff like that. Um, the lists and the property changes. Um, I'm thinking at some point. There may be a world where they need, like, um, it's almost like a code merge editor or like where when you're viewing changes in code and there's like the green and the red that shows you like, oh, these lines were added, these lines were removed in this place.
You know, it's, it's not quite that nerdy, but like they will probably need something like that when they allow. Edits for conflicts, pushing back up like, Hey, these properties already exist. Do you want, you know, obviously you changed this, but between the last time we saw it and now this was edited and this was edited, do you want the copy that's in production or that's in Sandbox, right?
They're gonna need like some level of conflict changes where it scans and scans both sides. Runs through a checklist of however many things that it wants to confirm. And you, you know, I'm sure they'll let you just say choose all or whatever if you wanted, but that could be dangerous. But, you know, again, I think there's a world where that's gonna need to happen to allow non net new and, and edit of existing assets.
Um.
George B. Thomas: So, so let me ask one more question 'cause my brain is going all kinds of like sideways, left up, down over here. And then Liz, I promise I'll shut up and you can continue to herd cats the rest of the way through the show that we need to. Um, I'm
Liz Moorehead: Hey man, I'm just giving space for nerds to be nerds nerd away.
George B. Thomas: am, I am, I'm, I'm just getting started with HubSpot.
I fire up a sandbox. Do I go in and actually go to, uh, data management and go to data model and do I build my data model in the sandbox and then once I'm happy with it in the sandbox, then deploy it to the, again, I'm trying to figure out these scenarios, whereas that
Chad Hohn: Like if you're just Yeah, if you're brand new HubSpot. Empty HubSpot,
Max Cohen: It's build and pro.
Chad Hohn: yeah. Build in prod because it's, you're not affecting anybody and you don't have your whole list of contacts or you know, you haven't uploaded all of your data data in there. Um, the only time I might suggest that is if you're planning on doing like a mega mega upload or something like that.
Um, maybe what I might do is build what I think is the right data structure in sandbox. Push that data structure up to prod, do a mega import inside of my sandbox and make sure everything checks out. Otherwise, then I have the opportunity to nuke the sandbox and pull that copy back from prod into Sandbox.
Uh, but again, remember that you only have those five assets to work with right now.
Max Cohen: Yeah. Also, like I, I don't think anyone should, you know, overthink this like. You can test stuff in prod, like it's not a pro, not an issue, you know what I mean? It's just like, it depends on the size of its impact, you know what I mean? And like how detrimental it could be if it, if it goes bad, right? Like, don't be afraid to like experiment in production.
Like there are plenty of ways to, like, when you're building a workflow, there's plenty of ways to isolate the workflow so it doesn't touch your other data, like when you're, you know, like, so it's, it's, it's one of those things where it's like. Unless it's a really, really big project, it probably doesn't need a sandbox.
Right. Um, so 'cause again, it's like a process to spin it up, get all the stuff, imported it, like you maybe delete it. Well, you know what I mean? It's, it's, it's a thing. Right's not a, it it
Chad Hohn: Another thing too is like when you do a sandbox, all the workflows that you have are turned off as after the sandbox is created. So like whatever you built in prod, you basically have to go. I, I think it also, I dunno if the new sandboxes import your user interface, but the old one definitely didn't.
Max Cohen: Like the record, the record
Chad Hohn: record structure Yeah.
Max Cohen: Oh geez. That would make me not even use it. That's
Chad Hohn: Yeah, the old one definitely didn't, um, I haven't checked the new one, actually, I don't even remember. Um, 'cause it's been like a little bit since I created my, I, I went in and did a whole bunch of stuff in there and pushed it up for an integration that I was building.
Um, so, but it was missing some stuff still, unfortunately. So I used another tool to import my record structure and a couple other things.
George B. Thomas: Yeah. Love it.
Chad Hohn: And, uh, yeah. But I think that that's one of those things that's a little tricky, right? Is making that decision. But the, what I, what I, what you asked earlier, George, like, do I build it in sandbox?
Actually, I'm gonna change my answer to like apps, uh, brand new portal, probably never in sandbox. And the reason is because of the limited assets. Now in the future, if it is like a full, you know, forward reverse kind of a thing, you know, then. You could do either way. It depends on what you really prefer,
Max Cohen: Still just extra work though, you know what I mean? Like to
Chad Hohn: Yeah. I mean it
Max Cohen: going on in production, then.
Chad Hohn: yeah, if there's nothing in production, but I think the thing about it is like when it comes to like an actual development lifecycle and actually building things like from the perspective of, um, like if you were doing it. From like a development perspective, you would always start in dev no matter what.
You always start in dev. If you're developing something, you always start in Dev, right?
Max Cohen: True. I just think, yeah, I just think, um. You know, like for, for us to get to that place, like the, it's obviously the, the sandbox has a long way to go in terms of like what it can push to production,
Chad Hohn: exactly. Yeah. So if,
Max Cohen: up rebuilding shit manually. You know,
Chad Hohn: Yeah, if we're at a place where you're not having to rebuild anything manually and you have the ability to do, like reverts almost like, you know, you're, you work in your gi repo, right? Like, oh, I'm gonna go back to this check-in, and then sandbox is back to whatever I built five check-ins ago, and then I can push that all back up, you know, or whatever, right?
Like those sort of things I think are theoretically possible. Um, but it, it is gonna increase the complexity. As well to allow that level of functionality. Right. Uh, right now it is very turnkey. It's like if these things work for you, you click a button and she works. Right.
Max Cohen: Chad, do you think they'll ever bring it down to, uh, pro,
Chad Hohn: I could see it. I mean, a lot of things that. Like, for example, custom data sets were enterprise. Now you get a cut down version, right? But they're pro now. You can make custom data sets with custom calculated properties. In pro you have less properties you can make. But like in a pitch, it will allow you to make a report that you absolutely never could have made in HubSpot before.
Max Cohen: Yeah.
Liz Moorehead: So let me ask you
Chad Hohn: it's totally possible.
Liz Moorehead: We've talked a lot about really interesting updates here, but is there anything that's still missing for us? Anything we still want to see? Chad? I see that smile.
Chad Hohn: Yeah, always. I mean, definitely ver like version control will be one thing for sure. So that's huge. We were just talking about that. And then additional assets like. You're gonna ultimately like and Max, I mean you, you mentioned the edit, right? It's only net new properties. So if you need to edit the description of a property, for example.
You're going in and doing a mega overhaul and you just are taking your time in sandbox and maybe deleting properties that don't need to exist anymore. Adding descriptions to properties that somebody just jumped up and didn't put names in. But you can't push those changes right now up to production.
Right. So I think that'd be really killer. Um, you know, so both delete and edit would be amazing to have, even just on the property schema level.
Max Cohen: Yeah, and I think also just like record layout stuff is a really big one. I mean, record layout stuff is, is one of the biggest reasons, like I feel like. Sandboxes would be useful. Right. Just
Chad Hohn: Mm-hmm.
Max Cohen: you know, you, you have to do, it's a lot of work to go in and completely like, restructure like your UI and your, your, your record layouts and all that kind of stuff.
And like, it's also something that can like stop people dead in their tracks from working 'cause they like can't find where a piece of data went or they don't know how to navigate the tabs on a certain record or where to find the data they need. Stuff like that. Right. So I think like. Moving to support that as fast as possible is, is probably a really important thing.
Um, you know, so that, and also, like, I wonder if there's like anything creative they can do around how to handle like, connected integrations, you know what I mean? Like when you do a, you know, developer portal, like you don't have any of your integrations still hooked up, or not a developer portal, a uh, a sandbox, right?
So like, you gotta go like. Reinstall apps, reconnect stuff. Like sometimes that's not so easy with like, you know, like, you know, for when we have customers that want to do, um, you know, an event Happily Sandbox, we effectively have to give 'em like another license for free to go do that. Right? Which is like kind of goofy.
Um, you know, and so I, I, I, and I'm not sure like what the answer is to that because like the developers and how their apps works is always gonna be like a variable there, right? Maybe it's, you just
Chad Hohn: they have to give a framework on the app partner side for Sandbox. They have to actually have a supported. You know, dev test, or sorry, prod test branch where all your URLs change and all of your database changes because you can't just connect up somebody's prod data. So that also means that whatever that partner is has to have a level of sandbox functionality for their tool in the first place.
Max Cohen: Yeah.
George B. Thomas: It's almost like, um, my brain goes to, my simple mind goes to like it in the future. If it was just almost a mirrored version, like, and it automatically kept up to date, but then you could like make changes and push it over and then like, yeah. Interesting.
Max Cohen: Yeah. Yeah. I mean, yeah. I mean, I think ultimately that's, that's where they're moving, right? Um, but I'm sure there's, you know. Drawbacks with doing like a complete mirror also, you know, like there's, I think sometimes there's, um, there's a benefit to having it be a snapshot just in that like, it's not gonna start changing while other people are making changes in production.
You know what I mean? And like screwing up what you're doing in sandbox, right. Um, but yeah. Weird.
Chad Hohn: Yeah. So I did double check, um, the new version of the Sandbox. It does not pull in the UI structure. So it still has the default HubSpot about this deal card. I can think the reason is because the, if you have integrated apps and they're not there or something, I mean, maybe they just omit those, but if those possibly could cause some sort of issue.
Um, or if you've installed, um. Like a UI extension. So you've made a custom HubSpot UI extension and it's in prod, but it's not connected to your sandbox, obviously. Um, 'cause that doesn't have like splitting. Um, I could expect that. The hard library that we now use for the record editors, right. You know, you have like the side panel that comes up when you're editing the structure.
Those hard editors, um, would have properties in them that wouldn't be able to exist in the sandbox theoretically, or stuff that could theoretically not exist. So right now they're just completely omitting it rather than like. Parsing out the stuff that's missing or putting placeholders in, you know, or something that will allow them to still exist, you know, or some way that it says this is in production, but it's can't be in sandbox.
So you could still have everything. Uh, because here's the thing is like when you build something in Sandbox and you add a record editor like that, or a property card or some sort of structure. For the user interface of Sandbox, then you have to manually recreate it in production. You also have the possible missing out of making it exactly the same or some sort of conditional logic that you forgot to add, you know?
So I think a big piece would be adding that data in. Um. Then the last thing while we were, we were talking about the developer sandbox in the enterprise accounts. One thing I wanted to point out that's really, really, really, really helpful for your developers outside of just them spooling up a free dev account is the fact that it has your HubSpot structure.
So if they're building a HubSpot user interface extension. Then they already are gonna see all of like your HubSpot portal properties and associations and association type IDs if you have custom objects and often like you want to interact with a custom object when you end up dealing with the user interface extension.
So that's like one reason that it's extremely helpful for your developer to work out of your enterprise developer sandbox rather than just the freebie. Developer sandbox. Also, they'll be constrained to the limits of whatever your subscription is. So if they want to use some sort of fancy technique, but it's a hub you don't pay for, for some reason, um, they'll have to live within, within that world as well.
So if you few cup, couple extra things as we round the corner here.
Liz Moorehead: Yeah. Well, let's round the corner and land this plane, shall we? George, what is the between one and 23 things you want our listeners to take away from today's episode? Just one.
George B. Thomas: no, just one thing. One thing. There was a word, I think it, I, I think it was Max used this word. Um, I'm, I'm almost positive, and maybe it was used by multiple people, but the word is impact. And so my one takeaway is like, when you're thinking about sandbox and if you should use a sandbox or not use a sandbox or do something in Sandbox, if you're using sandbox is impact.
And, and I would suggest that maybe you come up with like a, you know, small, medium or large gauge around impact to the team. Impact, well, actually, let's just say impact to the people, impact to the platform or impact to the process, right? So think about those three layers, the word impact and small, medium, or large to know where you should be building or doing the thing that you're doing moving forward.
That's it. One thing.
