Description
Great release management means different things to different people — the nuances of each company mean no two implementations are the same. So how do you ensure you’re delivering a great user experience? And how do you identify what great looks like for your business?
Gearset teamed up with Vertiba, the top-rated Salesforce implementation partner on the AppExchange, to explain how they leverage Gearset to deliver even more value to their clients and make release management ingeniously simple. Implementation partners, with their consolidated experience across hundreds of projects and clients, have the knowledge and tools to deliver world-class solutions tailored to your business. By combining their experience with the right tools for the job, implementation partners can remove many of the troublesome blockers and enable you to focus on what’s important to your users. Catch up on this webinar with Kevin Boyle (CEO, Gearset), Jason Mann (Head of Operations, Gearset), Chad Kelly (Director of Technical Architecture, Vertiba), and Jeremy Case (Solution Architect, Vertiba), as they discuss the challenges faced when approaching clients and how best to solve them.
Learn more:
Transcript
Hey, everybody. Welcome to, today's webinar.
We're talking about how to use GearSat for implementation partners. So those of us in ecosystem that are, doing consultancy and get into client organizations to develop a salesforce practice and how you deliver world class salesforce release management in in that scenario.
I was lucky enough today to partner with people that know a lot more about us a lot more about this in the form of Fortiva. We'll go into introductions in a few seconds.
So as always in these webinars, if we just go through it out, we got myself, Kevin, the CEO of Gearset.
Feel free to ask questions throughout all this.
Either use the q and a thing, in GoToWebinar or just hit me up on Twitter, kefffromarland.
I've got one of my colleagues with me as well.
So So this is Jason. I look after the product and customer success side of things at Gearset. And, again, you've got my contact details for LinkedIn or Twitter or anything like that up there as well.
We have much more important people with us today that are gonna talk us through what, Gear Set's like for the Matisse Partners. So I'll I'll hand over now.
Good morning, everyone.
Chad Kelly. I'm the, director of technical architecture with Vertiva. So, feel free to hit me up on on Twitter or LinkedIn to, continue the conversation.
So I am, one of the few certified technical architects in, the Colorado area, which is, where Vertiva is headquartered.
And joining me here today is Jeremy.
Hi, everybody. My name yeah. Thanks, Kip.
Thanks, Chad. My name is Jeremy Case. I'm a solutions architect with Fortiva.
Again, feel free to contact me if you have any questions. This is the world that I live in on a pretty regular basis in, dealing with deployment to some of our larger, more complex clients. And so, I might be able to offer some insights to you on how to best utilize the gear set for your deployments.
So just a little bit about Vertiva.
We are an active element of Publicis dot c p n. So our our parent companies, they bring, advertising and digital agency capabilities to our our suite of services.
Vertiva is solely focused on, the Salesforce platform. So we we do change managements, app cloud, sales cloud, communities, service cloud, marketing automation, and have, about eighty plus consultants, that are that are certified, and, including some MVPs as well, and then myself who's a a board certified TA.
So we've been a gold partner since two thousand and fourteen.
We're actually the number one, AppExchange reviewed consultancy, and we have about nine hundred projects under our belt.
So we use a methodology called value path to accelerate value with our with our customers, and it's specifically designed around agile and Salesforce, and our internal tools to to capture requirements, manage tasks, drive, drive projects forward, and we focus on the public sector, financial services, and and health care industries.
So just a couple of logos that we've had experience with. We I've mentioned we have nine hundred plus projects, so quite a few additional customers that are not on this list, but, all of our customers have, really been, successful with the Salesforce platform, and we are committed to a hundred percent customer satisfaction with with all of our engagements.
So just an agenda for today, we're we're gonna really walk through at a high level challenges that we face as a implementation partner and leveraging, really just around release management, and and deploying changes, being agile to to accommodate business requests and get those into the form of delivered functionality in a production environment, and how we go about solving those challenges in a world class way, leveraging Gear Set as a fantastic tool for for enabling a lot of a lot of that.
So at a high level, challenges that that we face when we are, engaging customers, when we're when we're in the trenches of projects is, evaluating the state of client orgs. A lot of times they'll they'll have an existing footprint, existing code and configuration that we'll need to have a point of view on, so that we can effectively make recommendations and and and do development.
So they may tell us their environments are in sync, and we you know, most most times, most often than not, they're they are not in in synchronized. So it it is a challenge to to to understand who's doing what, what has been deployed, what is active parallel active development.
And a lot of times we'll do parallel development with with our clients. And then even internally, if you are not familiar with Salesforce's metadata API, which a lot of your your customers are not, It is complex.
Deployments are, they can be challenging, and they they can be a bit of a pain. So it it hasn't been uncommon for that to fall on the shoulders of a very small group of resources that are are very technically advanced that, can work through a complex deployment.
And what that leads to is a very non collaborative deployment where you throw it over the wall on, you know, one or two resources, and they, they have to go and figure out, okay, what's changed? What what components, are candidates for for release based on client and and project team developers making making updates.
And then Jeremy's gonna talk a little bit about the collaboration aspect.
Yeah. Thanks, Chad. You know, as I said before, you know, I this is kind of the world that I live in on a pretty regular basis. You know, I I tend to work on some of our more some of our more challenging and and complex complex projects. And one of the biggest challenges that I face on a regular basis is working together with client teams who always have work in flight. They're they're, most often, they have some initiative or or some some changes that they're making, somewhere in in their, in their organization.
And, you know, having having people making changes in in multiple sandboxes or directly in production and not having any idea of what was changed, when it was changed, why it was changed, makes for a a very challenging project because you'll be developing to to develop to, to deliver specific functionality.
And, an admin somewhere could change a validation rule or, or update a profile somewhere in production, and that can change the, that can change the expected behavior of your development. It can break what you're building. It could allow access that they that that shouldn't be allowed. And, knowing what happened when and and by whom and for what purpose is, is always been a a big challenge in in that world. And that also, obviously, leads to, overriding changes. So you'll have, you know, somebody building something in the sandbox somewhere and deliver it up to production.
You're you may have another team that's developing another sandbox and overwrite their changes.
I'm I'm sure these are not challenges that that are not based on on virtually every project.
One of the other things that are, that is a a big challenge is destructive changes. If you need to delete a field or delete validation rule, that's not a big problem. But if you need to to delete an Apex class because you have, because you have upgraded that that functionality somewhere, your standard admin can't do that. It it generally takes somebody that's that's pretty proficient with with how everything is laid out, with what the, with with what the components are that are that are in place there.
The other thing that we find once we get into actually doing deployments is finding all of the dependency.
So when we deploy a field, what else is involved in that? We probably have a profile. We may have some and then when we deploy that profile, we may have some, some access, some visual force pages. This just leads to that complex metadata API that Chad was just talking about and being able to to identify what all those dependencies are in order for this great functionality that you've developed in order for that to, for that to be available once you move into a into a production environment.
So those are just some of the some of the major changes or challenges that we we face, especially on as our projects get bigger or we have parallel work streams where multiple people are working on multiple projects at the same time inside of larger organizations. That's almost all of the case.
Thanks, Jeremy. So another aspect that's obviously something that we we strive for is leaving a legacy with with our customers. So that means, you know, from a lease management perspective, building a reliable and repeatable release process, which, can be challenging depending on the maturity of the customer.
Sometimes they they may be more mature than others. Sometimes they're looking for us to, give them a strategy. Sometimes they have an existing strategy, and they want us to play nicely with with their existing policies and processes.
So, in terms of of leaving a legacy, we we always wanna be able to integrate with with client teams and and provide that thought leadership around Salesforce release management, but, make sure that, we work with with what they have in place as well.
And in terms of quality releases, you could have the best development. You could have the best quality assurance testing. You could have, the the best consulting services driving, synergy with with your with your clients. But if you botch the release, when when game time comes and, you need to get something into production and you miss a dependency or you, you miss the window that you're given to to get that functionality into production, then you've you've really hurt hurt yourself from a, from a confidence perspective from from that customer.
So to be able to to demonstrate value from cradle to grave on a project, you really have to to nail deployments as well.
So that's what we strive for, so that we we can build that that confidence with with customers that we can execute successfully.
So as Chad and Jeremy have just said that they've outlined in a very clear way some of the challenges which face implementation partners when they're approaching clients to deliver great projects.
And at the start, we talked about gear sets. So who is gear set and why are we teaming up with Vertiva here to talk about release management?
So Gearset is a tool that's designed to make release management on Salesforce platform ingeniously simple. So it was born out of decades of experience of release management across databases and different platforms.
And the idea is to make deployment and release management simple, repeatable, and effective.
The idea is to have a tool which is all the power of the metadata API and for those of you who are familiar with it with a tool like Ant, but then encapsulating that in a declarative user interface based tool, which gives you the mix of powerful functionality but then lowering that that technical barrier to entry to make effective release management available to a wider range of people.
So the tool is also designed to be flexible in terms of the licensing and the use to be especially useful for consultants and implementation partners.
So because there's no footprint when you install it and the the fact that you can attach as many different orgs as you like on an account, it's very easy to take it between different engagements.
So what what we're going to move on to in a minute is Jeremy and Chad, are they gonna start looking at how they are starting to leverage gear sets to help them address some of these challenges in release management, which they've previously mentioned.
Alright. So let's let's start with discovery.
Great looks different for for every client as I as I kind of alluded to. You know, some have, and we we span the gamut with customers we work with. Some are SMBs. Some are, very large established enterprise customers.
So we'll have varying budgets, varying team size, varying talent that they have on the team.
So we've we've found that the tool gives us an extra layer of flexibility around understanding, what's changing in the environment.
We'll talk about org monitoring as a as a feature.
It also gives us rapid insight into client orgs, so we can we can quickly compare, two different orgs, two sandboxes or sandboxes in production, and the tool will highlight the differences between those orgs, which from a quality control perspective, it really really gives you a great idea of highlighting changes and and highlighting relevant work that that's happening that you may or may not be aware of.
Also another huge advantage architecturally is Gear Set has no footprint, so it doesn't require you to have any kind of managed package that's installed within your clients' orgs. It's all, web based, and it interacts with these orgs, through the through the metadata API through through integration, which is which is great when you're you're dealing with as many Salesforce orgs as as we are.
So I'll kinda quickly give you a demo on how to do an org comparison.
So I've actually just logged into the, GearSat user interface at app dot GearSat dot com.
And what I can do here is I can just compare two demo orgs, that I that I have here.
It gives you the flexibility to select which metadata, components, what what metadata types, you want to compare.
So I've actually already built a set of sets of metadata types that I use. So for this one, I'm just gonna use code and objects to highlight the code and objects, but you could go in and you could add, you know, if you're doing email templates or custom objects or reports or roles, you could select what what you want in scope for the comparison.
So if the demo gods are nice to me, this should kinda quickly do a comparison. So what it's doing is it's it's logging into my source and target org. It's highlighting the differences between, those two orgs, and then it should give me a comparison that I can use to create a deployment package.
So as this is running again, the the thing that I just love about this tool is the org comparisons as a means of quality control. And as soon as I saw this product from these guys at Gear Set, I they just nailed it in terms of, giving you a web based tool to allow you to do these org comparisons. And it it although we do document change as we're doing it, there's there's always iterative components to a development, to a deployment.
So this kinda gives me an idea. You can see all of these, components have changed. If I were to drill into it, it gives you the details of the change. So this is just, you know, an API version difference, but because it actually gives you the the screen comparison, it's even more detailed insight as you as you drill down into them.
So I'm just gonna look for a specific field called account source, which I've updated in my source environment. I just added a pick list value, and now I wanna deploy that to my target org.
So another nice thing about Gearset two is it'll do a dependency check.
So if if you're familiar with the metadata API, you you may know when you when you execute a deployment, if you're missing a dependency, it it could take a long time to process. And eventually, Salesforce will give you that feedback, but it's it's a very expensive call. It takes a lot of time for for Salesforce to to try to execute your deployment and give you that feedback.
Gear set actually pulls some of that dependency checking forward. So for example, if you were to try to deploy a object that has field history tracking enabled, and that is not enabled in the the target org, it will warn you before executing that deployment.
So it gives you that feedback faster, and you can ultimately iterate a lot faster.
So I'm gonna go ahead and deploy my change, and then depending on how many components you have, it'll, you know, be very quick or or take some time, and now I have a successful deployment pushing that change to, to my production or or target org.
Okay.
Jeremy, do you want to talk a little bit about the collaboration aspect?
Yeah. Sure.
Chad kinda hit on the, the monitoring and the I'm sorry. We'll be zipping on the the org comparison. One of the things that I wanted to talk about was the the, the org monitoring. So within Gear Set, we can turn on a a feature that will monitor changes to an org.
And so every day, it will look at what the what the org looked like the previous day and what it looks like today, and then highlight each change that's been made, to to as many different orgs as you want, and then send it to you in email, or or whatever. So that whenever a change is made, you can tell who made it, and and when they made it. And if there's something that's unexpected, you know who to go to to find out what the what the reason for that was. That was that kind of thing was really, really difficult to do, prior to prior to using a gear set, and it really helps to, to monitor or to to maintain integrity of your, of each of the orgs that you're that you're working with.
And because of that, it really helps to to integrate with client teams who are working on parallel works, sometimes in the same sandbox, sometimes in different sandboxes.
And so if you if you highlight changes, that look like they may override one another from two different sandboxes, or if you're monitoring production and you see a change made in production, that's that's generally not something that we, we expect anybody to be doing to make a change directly in production, when we have when we have projects in flight. So, that gives us a, that gives us the ability to to see what that change was. And it might have been a legitimate change. There may have been something that was that was wrong that needed to be fixed that needed to be fixed immediately, And that's okay. We can pull those things back back up. We can pull those changes back upstream so that our development and our, and our, UAT environments are in sync, so that whenever we go to deploy, we already are taking into account whatever change was made, in production.
So then again some of the other things that Chad has shown you and then the things we need to get into in a minute is, you know, we can we can automate some of the some of this functionality through some continuous integration functionality that's starting, that they were starting to see, Gearstead really do a good job of. And then we can see what's happened. So each of our deployments is kept we can track what we can go back and look at each of the deployments that has been that has been done and see what components were deployed with that. And not only that, what the contents of those components was.
And so it really it really helps us push changes effectively from one instance to an from one instance to instance to another.
Thanks, Jeremy. So I'll just kinda quickly give you, some of the show you some of the features he was he was referring to.
So if I were to go to monitor orgs, you can see here I've got a smattering of of clients, that we've got this set up for. So what what we can do here is we can actually choose the organization that we wanna monitor, even our this is our internal instance of Salesforce that we leverage. Again, select a metadata type set of components that I wanna monitor, and then, I can have, email results sent to me or texted to me or my my project team or my customer, even integrate with Chatter if you don't wanna see a lot of those notifications.
And it'll give you visibility on, you know, how many deployments are being run, what what's changing, if if they've changed from the last time the the job was run. And then if I'm interested in drilling into that, I can actually go and drill down into the the details of of actually what objects changed. So no matter how close you are to a project or how far you are from a project, if you want this visibility, it's it's a very, it's a very nice tool to, to to give you that.
And then you also have the ability to, collaborate on deployments. So if I were to select, you know, a set of Apex classes and objects and Visualforce pages that I want to push into production, push into the next sandbox, I can I can start building that package, and then I can do what's called a draft deployment? So I can I can give it a name, and what what's cool about this is, now I can copy this, or they can log in to Gearset and, and browse to it? I can share this with the client team. I can share this with the project team, other team members, and say, hey. Did I get everything?
So again, it's it's taking that deployment burden that used to be very, siloed into, you know, the your guy that does deployments, and it makes it collaborative. It makes, improves the release quality because everyone on the team owns the deployment, and they have buy in, and and they have visibility to to what's changing.
And then from a test class perspective, test class in the Salesforce ecosystem is always our favorite topic.
We have this monitoring capability. So as a project manager, as a technical architect, you wanna know that your developers are keeping pace with the seventy five percent, code coverage requirement. So I can set up orgs to, again, be monitored to make sure that they have the code coverage up to snuff. And we all know that changes over time too as as new codes added, as as validation rules are added, that could prevent previous test class coverage from being run successfully.
So you can actually set a threshold, and you say, okay. I wanna be notified anytime the code coverage falls below seventy three percent because I we know we don't need more emails in our inbox.
And then has Chatter integration as well if you want to, have that more collaborative in the org itself.
Another great aspect about some of the features that I just went through from a technical director perspective where where I sit in the organization, I'm I'm responsible for technical excellence across all of our projects and provide leadership to our technical resources.
So I I don't necessarily have time to be on the ground at all these projects, and some projects may be more configuration based where they have a business analyst, or some may be major projects with the project manager and multiple developers, or maybe it's a TA and a developer.
But no matter how large or small the project is, if the project teams are leveraging Gear Set, I actually have visibility into those, the progress that they're making. So I can I can track their test coverage? I have visibility at a at a technical director level even though I'm not engaged in the day to day, for those projects, which is which is just a fantastic tool for me to to be able to to to stay engaged and and get involved if if necessary.
And then in terms of leaving a legacy, again, just having the tool to be able to to be flexible with customers and adapt to their release management needs to improve our agility getting code from dev to test to production in a in a in a way that's quality and and and fast manner.
That that really is is at the core of what we do in addition to development and and quality assurance and and consulting services. So it's a very nice complement to, to our consulting tool set.
And it also provides some nice artifacts as well. So if I want to provide some release notes, I have the ability to go in and do an export of of the comparison history or an export of the deployment itself.
So I can go look at my deployment history and ex and export the the components that actually changed because, that's input that customers care about. They they wanna know what you did and when you did it.
And another nice feature is, the ability to do a back out.
So I can actually go into the deployment history and back out a, a given change, which as if you're familiar with Salesforce, they don't have any native back out capabilities. They have one version of your code and configuration, and that's it. So, the fact that it keeps a a backup of your, previous wait for this to load here. I I have a lot of deployments here, so that's probably why it's it's thinking. But, a lot of customers, even even if they don't necessarily want to to back out a deployment, it they have a nice warm and fuzzy to know that that that capability is there.
It also integrates with looks like it's running again here.
It it also integrates with source control too.
The GearSight guys are also gonna talk to you a little bit about some continuous integration functionality that they're rolling out, which is very cool.
But all in all, again, it really is, a nice toolset that helps us improve the quality of our of our projects.
So just at a high level, I kinda go through the, you know, sample release management process involving Gear Set. I mentioned we do have traceability to changes that that our developers make, and and we put that into what we call a deployment document. And that is it really just highlights all of the necessary steps that need to be involved in a deployment. So the components that have changed, the manual steps, the packages that you need to install in the in the orgs if you're using AppExchange partners.
So we we try to get everything in this deployment doc, and then we we kinda use that as the basis for for creating that deployment package. But as I mentioned, things are oftentimes, missed. So if you have a client team that is making changes that you're not aware of or maybe a developer forgot to include a a component in their notes, we we can highlight those dependencies and those components that may have been missed with the comparisons.
So what we'll often do is we'll have, you know, a mock deploy from dev to staging. We'll iterate through that using the deployment doc and the the comparisons to highlight change, and we'll kind of incorporate that back into our our deployment doc with the goal being you just have one, one and done deployment from from staging into production because you already iterated through some of those missing dependencies when you've when you did your your step two mock deployment.
So just just to go back to the comparison history that that's been made.
Again, the rollback feature, if I wanna export the the artifact, there's there's PDFs that that highlight the the release, the the deployment itself. There's also, CSVs you can export with, the full inventory of of deployment candidates.
Okay?
Thanks, Chad. So I'm sure everyone on the webinar is used to hearing vendors say say how great their tool is, but it is really, really refreshing to see all the company and to see Fortiva using it so effectively. And we've got a few quotes from other users as well that really helped to quantify the improvement the teams are seeing. So you heard from John, Jeremy, just how much time it's saving them and how easy it's making, life for them engaging with their clients and delivering a great experience, delivering that customer success. That's got them the the number one rating for implementation partners on the AppExchange.
We see, bright common stories from lots of different people. Julie at the Zaxis sort of talks about how you refresh the sandbox with the clips and the manual dev just would take days and days. They tried to do this at the start of every sprint or, you know, as often as they could, make sure their environments were within sync. Now they use gear sets.
It just takes an hour or two. And that allows people to do, you know, more useful work. You know, these things have taken eight hours to do deployments. No one wants to spend that time.
That's not really helping the customer.
And, we hear we hear that a lot. So it's it's really nice to hear that we're team again. He's, having a great experience too.
To think of a worked example, you know, it's it's not uncommon for us to hear from customers. We try to check-in and see how they're getting on with the product.
And so we think of an average team size, maybe five days on a on a project. And, you know, we've used the word developers there, but really, as Chad and Jeremy said, your your GearSat allows you to to lower that technical barrier to entry. So you've also got business analysts and admins and, you know, end users of Salesforce who are able to now understand the differences. So before you might have had five people on the team spending, you know, twenty plus hours a week migrating, tracking changes, trying to debug into field tests, trying to understand what production looks like or, you know, having a conception of what production looks like. And then you come to a change and you, you overwrite something that was that was made.
Think about six six sprints a year. We think that with GearSat, you know, we reduce that down to three hours per sprint. So, you know, easily in the in the first year, you see about sixty working days.
And what we don't just promise is that, time saving alone, it does whatever that we wanted to have a fundamentally better way to do deployments as well. So we try to get that deployment success rate up through things like, the dependency analysis and all the problem analysis we do to work around, let's let's call them quirks of the Salesforce platform.
We want the deployments to work first time every time. We're not quite there yet, but, you know, we we track and track and track and improve and improve and improve.
We also try to improve collaboration of our users. So allow them to work effectively with their teams or within their team through, you know, draft appointments, first and foremost, to be able to collaboratively build up that package so you can, work together instead of, working against each other.
In collaboration through, our automation, so you're alerted when your tests start to get close to that that failure zone, that seventy five percent zone. And also learning when your production changes are made because we all know that the power of the Salesforce platform comes the ability of end users to make those changes and not have to go through rigorous step cycles. That's, you know, that's why we all love the platform. So the production org monitoring allows you to keep that capability and just bring those changes back into your dev flow so that you can, you can keep everybody happy.
Your dev teams are happy. Your end users are happy. You generally have happier users and developers on the platform. All that comes together to just have faster releases, and that's, you know, that's kind of the mission of what we're up to here.
It's it's great to hear from Deepa. I've had I've had such a great experience.
As we, look forward to Dreamforce, we are gonna be out there as soon as we were last year. We launched last year, and it was fantastic to hear from, to hear from so many, devs and admins in one place. We're out again this year. We're gonna be in the dead zone, so come and find us there. We're gonna be demoing end to end ALM with continuous integration. So we think that you find the right release management strategy for your level of sophistication and what works best for you just to see that customer success and see happiness from your clients and your engagements. But you can use GearsOut in a full end to end flow, end to end ALM flow with continuous integration, source control, bring it all up together so it's all automated.
We're also gonna show you how to, you know, get towards SOX compliance and do things like, have certain users be able to build packages, but only a release manager can actually deploy those changes to production. So the release manager can authenticate the actual production org and then give just certain users read only access so they can do comparisons and see how their dev environment differs from production but never be able to modify or deploy to production.
So that's all coming at the Dreamforce. Fighting for the dev zone. If you're not gonna be there, check out gearset dot com slash d f sixteen, and we'll be sure to say what we're up to there.
So that's the end of our webinar today. I want to thank you all for attending.
Thank you guys at Vertiva for sharing their experiences with us. I'm really open to any questions.
You can use the GoToWebinar chat window there where you should be able to ask some questions, and we'll be able to answer them for you. More resources available at brigiba dot com if you wanna find out more about that number one implementation partner or gearset dot com slash d s sixteen.
Do you use any so first question in, hi. Do you use in your orgs managed package? Is that I guess that question's I'll answer it on behalf of, like, Gearset first, and then the Vertiva guys can answer it. We'll take both interpretations.
So Gearset itself, sits outside of Salesforce, and that's you know, it's a conscious decision to have that in the old print. So when you make a connection between Gearset and a Salesforce org, we don't install anything. It just uses the same metadata API that the Eclipse dot IDE uses by the force dot com migration tool. So nothing to install, but Gearset then does have full support for managed packages.
So you can see the differences. You can, see differences in profiles or custom, custom theme permissions that you might have on, a managed package that you've installed.
I was talking to Jeremy if you guys have any experience using managed packages in, in your engagements.
Absolutely. Yeah. So I'm not sure if the question is more I think we touched on Gear Set doesn't have a managed package as a footprint. It really just lives outside like Jason is reiterating. But, yeah, we'll absolutely leverage managed packages, AppExchange products, and, we we've leveraged Gearset to promote those components as well. Or, you can also do the one click install in your production and and other sandbox environments as well as a means to deploy those.
Next question in.
When refreshing sandboxes, is there a way to move the data also?
Not at the minute. That's a that's a conscious decision we've made with Gearset. We don't wanna access your data. Your data is, you know, an incredibly valuable asset for your organization.
We think there's great products out there that do that phenomenally well, like DataLoader, JitterBitten, and a bunch of other companies. So what we have focused on exclusively is that migration of metadata, the migration of the configuration of your org. And, you know, that's we wanna totally nail that and get that to be at the absolute you know, the best of the market leader in that and leave, data loading for, for some other people. I'd say the the one thing that we might do is, the data that isn't really data, that sort of the meta metadata.
So the the, let's say, list of countries or, you know, the stuff that you might now use custom metadata type for, where previously you used the settings records, we might do that sort of stuff. But so far, we've made a real conscious decision to avoid access in any org data. And, you know, we're we're happy with that. Our customers are happy too.
Cool. Well, if you guys have any other questions, we'll send out an email after the webinar with a link to the recording.
Chad and Jeremy have given their, their their Twitter handles, and they're happy to take, comments and questions about, what they do and and, how they work. And likewise with us. So feel free to get us on Twitter or email us team at gearset dot com. And, yeah. Thanks very much for attending guys.
Thanks for having us.
Cheers.
