Description
Choosing the right branching and release workflow is one of the most important decisions a Salesforce team can make. Yet, most teams inherit a model – Gitflow, Feature Independence, or something in between – without ever stopping to ask whether it actually works for their scale, structure, or delivery goals.
In this session, Gearset experts Richard Owen and Jack McCurdy are joined by Mitch Spano, Director of Product Management at Salesforce, to unpack the strengths, trade-offs, and ideal use cases for both Gitflow and Feature Independence. Drawing on real customer journeys, hands-on experience supporting some of the world’s largest Salesforce teams, and perspective from the Salesforce product side, they’ll help you cut through the theory and focus on what’s practical, measurable, and scalable in 2026.
They cover:
- The core differences between Gitflow and Feature Independence
- How to choose the right model for your team’s size, culture, and structure
- Practical strategies to reduce merge conflicts, bottlenecks, and cross-team friction
- How Salesforce teams scale delivery in practice – insights from both Gearset and the Salesforce platform
- How modern tooling supports both models – and how to transition seamlessly
Transcript
Thank you once again for joining this webinar. I'm really pleased to be here for this workflows that works session, which encompasses Gearset's q four product launch.
Today, you have myself as your host. My name is Jack McCurdy. I am a DevOps advocate of Gearset. I've been in the Salesforce ecosystem for seven years covering all things DevOps.
It is also a huge honor and privilege to be joined by group product manager from Gearset, Richard Owen, who owns the automations and government governance side of the Gearset product. And, of course, distinct privilege to be joined by Mitch Spano, who may be familiar to some of you as director of product management at Salesforce for, developer tooling and experience. So I appreciate them both sharing their time with us today. In terms of an agenda, this is what we have in store for you.
So we are gonna cover all of these bits and pieces in various forms, the challenges that Salesforce teams have when they scale up, the different branching strategies available to us, a bit by feature independence, a bit by Gitflow, and try and get down to the crux of what branching model should I use based on where I am right now or where I am hoping to end up. But to really set the tone about where we are, why why do these workflows matter? Why do we need to be concerned about what branching strategy we might use and how our teams collaborate in version control together? So if you imagine a scenario, maybe your own team set up part of a global organization with multiple Salesforce orgs, one for North America, one for EMEA, or more separate orgs for each business.
How do you collaborate effectively across different work streams, across different regions, critical information going missing at the wrong time, maybe new compliance features for a specific market that can't go live, for example. All of these things become easier easier when implementing an efficient workflow, but a lot of teams get stuck in how do I implement that workflow? What should I do to get myself there? What we are really trying to avoid when using version control or Git, We're looking to avoid silos and disconnection from our other teammates.
But as we scale, as we get bigger, as our Salesforce implementation grows, we really, we really have the risk that we run into, we run into changes clashing, fixes getting lost, and people losing trust in the system that is ultimately designed to help them. So we are hoping to unpack some of that today and help you make better decisions about where we are going. So the businesses that choose stability over just progress because of the workflow that they have implemented. We are gonna succeed, and we hope to put you in that bucket.
But to get down to it, I think we need to explore branching. For this side of the webinar, I'm gonna throw over to Richard. Richard, welcome to the show.
Thanks very much, Jack, and thanks, everybody, for coming along today.
So one of the main decisions that you need to make is what workflow do you serve your team's process best? And one of the key parts of that is the branching strategy to choose.
So let's step back and send that step back a second. So what is a branching strategy?
Well, there's a set of rules teams need to follow to decide when to take key actions in their release process, usually using tools like Git.
So the key decisions are what parameters do you need, where should you be creating features from, and where and when to merge changes. And each strategy has its own pros and cons, trade offs which you need to bear in mind when making that decision.
Now there are lots and lots of different practice strategies out there, but today, we're gonna focus on two. One that's most commonly used by Teams using Giselle and other Salesforce DevOps vendor tooling today, mainly, yeah, mainly because of that support the vendors have for it, as well as a best practice model that's used more widely across software development.
So most of two of us use the feature independence model. So it's the first model we support in gooseneck pipelines, and it's the only model that's supported by most vendor tools on the market today. Let's take a quick look at how this works.
The big reason why I say popular is that it enables the same sort of workflow that change sets does but with all the benefits of version control, quality checks, and automation.
So in in in essence here, each change set is contained in a feature branch that only contains changes already in production plus the thing that you're working on. So that's can there's nothing that's already in QA or UAT. So how do we achieve this?
So let's follow a change to the process. The key question, where should we create feature branch from and when? So in this case, feature branches are always created from the the main or master branch, and that contains only what's in production.
This ensures that features are kept independent all the way through the process. Because if you branch from integration, that wouldn't be possible. And feature branches here usually map one to one to a user story in Jira or Azure DevOps or whichever system you're using for tracking work.
And the team needs distinct gates. That's QA and UAT for changes to be held back. If changes fail, then you need additional long lived branches which represent each of the environment that you're working with.
And then to keep those features independent, emerge from the feature branch itself into the environment branch when it's ready for that stage. And that trip is an automated deployment, which heads out to that sandbox.
And then finally, changes emerge back into the main branch for deployments out to production to make sure that you're getting those changes all the way through and live.
Let's make it real. This is how it maps to a team's actual process. So if you're starting with a small team, maybe, like, five to ten devs with a pretty routine path of production, it might look something like this. So in this case, each team member has their own dev sandbox, which isolates their changes, this applies to both devs and admins, basically anybody who's carrying out changes on the platform.
All changes are independent, so features can move past each other if needed. They can be held back if required. In this case, we've got a partial copy QA org, which is where changes are merged together and where early kind of integration testing is carried out. UAT is where business users come in and check and check that the changes meet their needs.
They align with business requirements, and then production is production. But as the team scales up, requirements end up scaling with it. And very quickly, you end up with a much, much more complicated setup, which may look something like this. So this is really it's a really common architecture that we see and work with a lot of our large teams on today.
So here, the volumes increase to the point where that unified team needs to break out into independent development streams, parallel streams, different project areas. So in this case, you may have team one that's working on service cloud, team two is working on sales cloud, a separate longer term project which is going on.
And the work from these teams, so from the BAU teams, is is released once a week to production.
Now as this team has scaled, they've got lots of developers lots of developers working on each team. They've all got their own dev sandbox for work, and they've added a separate team level QA environment.
You've still got a central integration environment where everything gets brought together, and you wait to QA test that for for the end users. But then you've got an extra staging all, which you use for a dress rehearsal for your production deployment. So it's a much more complicated setup. There are lots more steps on the route to production.
The number of environments is multiplied out, and you can see that teams will struggle to keep moving fast as the volume of changes also goes up. Because the number of dev has gone up, the number of features going through goes up. There may be dozens or hundreds of changes now waiting for validation on environments. And this robs the team of momentum.
Teams face a ceiling of productivity where they are growing to a halt. And I'm sure some of you have dealt with that. As you've dealt with crunches at work, Suddenly, nothing can move that fast because everything's waiting for something else to go.
And this has been a problem in getting changes through Salesforce using different Salesforce vendors and platforms for years.
But this model isn't doomed to failure. Far from it. There are concrete tips, tricks, and techniques that you can start using today. You're under this model, which can help improve velocity and make progress.
So with this feature independence model, how can teams who are encountering these strains, these struggles continue to move faster as the volume goes up?
So what we've learned again and again is that teams embracing those core DNS DevOps and embedding those those processes team wide. They see improved success across the board.
And these ideas won't surprise anybody who comes from a traditional software background, but applying them in Salesforce really does pretty magic to the process. So you got things like committing this runoff.
You don't wanna store up all your changes to create one massive PR. When you completed a sensible unit, work on a story, get it committed to a branch, and iterate on it. So that way, you can start shifting left on the other key parts of the process, reviews, code quality, most complex checks.
You wanna keep all of your working environments in sync and aligned with each other. Because if you're working on an outdated baseline, something that's unreliable, then you risk making the wrong changes or testing something that's already outdated.
Because if you're if you're on testing in QA and UAT content that's aligned with that in production, then you're not testing the right thing. And this raises the risk of regressions happening in production, and that causes downtime, and that costs a lot of money.
So get those environments along quickly, and you'll see the confidence in the whole process go up. And then when changes are approved, push them. Because if you leave stale changes hanging around, they're approved or undeployed. That increases the drift between between environments. It reduces confidence in the process. So in this case, really, green does mean go. You gotta also make a delivery of your approved changes to your testing environment and see that release velocity go up.
So each of those principles is shortens the distance between the initial idea and delivery into production. It reduces risk. It increases velocity. And you can do that whilst maintaining feature independence and good governance to the process. And we've been working with hundreds of teams at scale, implement those release processes incorporating these principles.
But this isn't the only way that we see successful and growing teams work in software because there's another model, one which we haven't seen commonly used in vendor Salesforce DevOps tooling before, which we believe can help teams move even faster.
So if you go back to that team structure and look at a third example.
On the face of it, yes, it's a similar environment structure to what we've seen before, but this team has taken on those principles that we've just been talking about. They commit little and often. They get their environments aligned. They move the quality gates and review process left to build confidence in what's going to production early. And that means that that team changes the way that they work. So here, they've got a collaborative planning process. They've shifted the development checks left so that you're doing them before you even get into the QA environment.
The dev sandboxes are in a good state with good test data, and the devs take a lot more of a shared responsibility approach to testing before shipping those changes into QA because they know that when the change gets there, it's then pretty much confirmed to go to production in the next release. So anything there is a fix forward.
And this means that that team doesn't need to branch from production. They don't need to branch from your main environment. You can branch from the developer onto QA, which means that developers gain the ability to meaningfully build on top of earlier work within a single release cycle. That QA environment becomes a reliable and tested state.
Then new AT becomes the final check of the release, and everything that's made it to QA is released every two weeks.
So those bottlenecks we've seen teams working around with the feature and events model can disappear here. This enables teams to move faster because you're shifting the key checks left. You're resolving the conflicts for good at the first stage in the process, and then you have really you increase the confidence that it's good to deploy when you're ready to go. And some of you have worked in wider wider software development. This this will seem really familiar to you because it's Gitflow.
So this strategy often takes this form. And it may look a little bit more complex initially, but it's actually a huge deal simpler.
As you can see, few along with branches here. There's only two to manage, main and develop.
So main maps to production, develops created from main at the start of the process, and maps to your intermediate environment, your integration, your EUA to UMS.
So let's follow a feature through again. Where did I ask where did where did developers create branches from?
So here, because you need to isolate features from each other so in the feature in the feature independence strategy, because you had to isolate features from each other, you had to create those branches from main. In this case, because you've shifted left on the planning and testing phases, you can branch from your developed branch. And this allows you to build on top of earlier work.
And then when it comes to the merging strategy for users, there's only one merge that you need to think about, and that is to merge back into the dev branch. And that means if your team can work in this way, the amount of merge it requires is dramatically reduced.
And then as you finish sprint, every so you create your release branch directly from develop. That contains all of those changes, which means they can then be turned calmed. It can be fixed forward, and then it can be merged back into your main branch for deployment out to production. It means you're dealing with a much reduced number of moving parts. It makes it a lot easier to deal with the whole process.
And we believe that teams who wanna work in this way should be able to as is aligned with good practice.
So we now support it as a broadening option in gear sets. And one key advantage to model is scalability. There's many fewer moving parts. Teams are iterating far more quickly on the same core branch so there are fewer conflicts, resolve to get more quickly.
You've shifted the decision making process left so you can be faster and you can release quicker using a simpler model.
Those barriers which prevented technically diverse teams from using this previously, so knowledge of ECS, knowledge of where to create stuff from, they're not really an issue here because you can create feature branches in the same way as you do through feature independence model off the developed branch, merge them in, create a release of that, and then that allows you to push those changes back into through your testing environments and then into production.
Now if the team regularly gets to UAT or staging and has stories held back or you got frequent drop ins from external stakeholders, then maybe feature independence is the right option for the team. It really depends on how you're working today, how the model which works best for your team dynamics, and how you want to work. But we think that for teams who can adopt Gitflow, they like to move faster and counter fuel conflicts and be able to ship more successfully.
So I'll hand back to Jack.
Thanks, Richard. Very enlightening. Thank you so much.
Mitch, we are joined by you today somewhat of an expert on all these things. For those that don't know, Mitch created a lot of the Salesforce release strategy, his previous employer, which some of you may know is Google. So, Mitch, I would love your take on what we've heard from Richard today and feature independence versus Gitflow. What's your take?
Yeah. Absolutely. First of all, just thank you all for having me. It's wonderful to be here with you all.
As Jack had mentioned, I've kind of spent a lot of time in this space. Recently joined Salesforce within the last year, and I'm the director of product management on the developer tooling team. So I am the product owner for the Salesforce CLI, the Visual Studio Code extensions, and a lot of these foundational libraries that we all, as Salesforce developers, use in our day to day lives to help accomplish things like DevOps and and other tasks that people do, as part of their delivery workflow. The best way that I could kinda describe this, bifurcated model, I think Richard did a did a fantastic overview of, like, graphically representing it.
But the feature independence, model that we all are pretty familiar with who have been playing in the space is essentially, very much akin to change sets with branches. So you have some features, and you're moving them from the place that you built them to the next stage. And then if you were in a change set model, you need to create another outbound change set from that that environment that you just deployed to and move it over and over and over again. So the the thing here is is, like, it's as if you are trying to get a package from a you you've got a box and it's got a gift, and you wanna deliver it to your grandmother, and she lives far away.
The feature independence branches, the feature independence model would be like, I'm gonna hop on a train, and then I gotta go to the train station, and I gotta transfer to a different line. And then when I get to this next station, I'm a transfer to a final line. And then finally, I'm gonna get to my grandmother's house. You're holding the package with you the entire time, making sure that you're transferring from train a to train b at the train stations.
K? Whereas the Gitflow, model is more so like, I'm gonna take this package that's for my grandmother. I'm gonna drive to the courier's office, and I'm gonna hand it off to them. And at that point, I'm pretty much done.
I know that eventually it will get to my grandmother.
Now the advantage of the feature independence model is that if I were to have a delay at any one of these train stations, I could stop off, and I could get another gift for her. Oh, maybe she doesn't like this purple sweater that I bought her. I'm gonna get her a blue one instead. I can make some changes either either way, and I can you know?
Oh, my my aunt lives over in Cincinnati. I'm gonna take some time. I'm gonna spend lunch with her and make sure that she thinks this is a good gift for grandma. If she says, no.
That's not a good gift, I have time to go to the store and get a different one. Whereas if I drop it off at the courier, I better make sure that it's good to go. So that's kind of the main difference here is you have all of these different steps that you that are intermediate within the feature independence model, and it's very familiar for all of us.
And it gives us the opportunity to check, hey. In staging, does this work how I expect? If yes, move it over. But there are challenges with that.
You can you can immediately see that there is this repetition within the workflow, And it could be the it could be that you make things up to the UAT environment, and then, you know, some project comes in and sidelines everything, and you forget about these changes. And they sit there, and they get stale. Right? So the repeated steps increases the probability of drift across your environments and your branches, just as Richard was saying.
And then in the Gitflow model, it's nice because I, as a developer, I have this kind of merge once and then walk away feeling. Right? It's like I'm dropping the package off at the courier.
But that means that the onus is on me to make sure that that can be safely deployed in all of those target environments without interrupting anything because I'm no longer manually saying, yes. This is good to move out of staging and into UAT.
So it it really forces a little bit of a mind mindset shift to make sure that, like, when I say this is up for review, I know that it will be safely applicable in all of these test environments. So some of the things that you might need to start thinking about that I'm not sure if, you know, a lot of these vendor products, I'm sure that a lot of them have support for all of this, but some things you're gonna need to start thinking about when you create that package before you drop it drop it off at the courier are things like environment variables.
Right? You might have an email address that's supposed to be different in QA versus UAT versus prod. We need to define those different addresses when you have the packaging the package as in, like, the the proposed pull request to get your stuff into source and move along because it needs to be ready to arrive at its destination when you check it in. So there's some mental shifts that you're gonna need to make as a team, but the advantage here is you commit once and then walk away. You can move on to the next task.
That's really good points, Mitch, and it kind of leads me nicely into a question that's been asked a couple of times here in the in the q and a, but specifically for when things do go wrong or things aren't quite right. Roll back in a Gitflow scenario. Can you walk walk us through that and what the ethos is behind that or the the strategy behind that is? Say, the package for grandma is exactly as you intended and you made sure it was her favorite color, and you made sure it was it fit the if the tea cozy was fit for the type of teapot that she uses, etcetera, etcetera, things sometimes still need to go back. What's what's the strategy there?
Yeah. So that's a very important thing. Like I said, you know, when you check this stuff in in a Gitflow workflow, you know that eventually it will arrive at production.
And it's not so easy to, tease out what it would mean, like, to revert a change because that deployment to production is not just gonna contain your individual changes. It's gonna contain everything that was, you know, clubbed together in the deployment, window or bundle per se. One of the strategies that I really encourage teams to take a look at is the use of custom permissions on the Salesforce platform as a feature flagging mechanism. So in case you're not familiar with it, a custom permission is a permission that you can create, and you can assign it to a permission set or to a profile.
And then the the cool thing about custom permissions is you can bifurcate your application logic across many parts of the Salesforce platform. You can check, does the running user have a custom permit have this custom permission in flows, in workflow rules, in validation rules, in Apex, in page builder visibility criteria, almost anything that you wanted. So you can essentially take that custom permission and say, hey. If the running user has this custom permission, show the new version of this component or show this component.
Else, take no action, hide the component, do nothing. And the reason why we wanna do this is because that will enable you to deploy your metadata up to the destination production environment where it can sit and lie dormantly until you assign the permission set that contains that, that custom permission, and you you're essentially bifurcating your technical deployment from your business go live. And the great thing about doing this is that if your business go live goes wrong, something's not working right, you don't need to scramble to do a metadata deploy operation. You don't need to wait for Apex test to run.
Instead, you can just revoke the permission set assignments and to turn off that particular feature. It's like an in in application on off switch. It's a very, very effective strategy. I don't wanna claim that it's a panacea.
There are certain things that cannot be feature flagged using custom permissions. For example, columns on a list view. You can't exactly hide a column on a list view using the custom permission. But for most of these core things that are very custom, you know, Apex, Flows, Lightning Web Components, all of these things, they all have the ability to check if the running user has or does not have a cost custom permission.
It's a very, very powerful feature for you to be able to deploy the components, let them sit dormantly, bifurcate your business go live from your, from your technical deployment. And then if something goes wrong, just revoke the permission set assignment. Everything is all good.
Yeah. Something that I think you've spoken on before at conferences. There may even be a recording on YouTube of a talk you did at Dreamforce or TDX about feature flagging, which I encourage people to go and check out for sure. Yep.
Richard, just to come back to you as well. For folks that are looking at sticking with a feature independence model potentially for as long as they can, it might have been something that they've been doing for a while. What are some of the pitfalls that folks need to steer clear of when they are growing and scaling and their Salesforce orgs are getting a little bit more complex?
Absolutely. I think one of the key things which we've seen sometimes from teams is a little bit of out of sight, out of mind. So teams who have features which store different points of the process, maybe they store an integration or UAT environment, and then they close the PRs. They close the features, but then they don't correct the drift. So you end up kind of codifying that drift between environments, and then you've got an unreliable state between the there's an immediate environment that you're working on and your production environment, which means that you're not you're not really setting something which is reliable anymore.
So key thing to do is to make sure that you're that when you do have things restored, you make sure that they are reversed out appropriately from the environments, that you're you're getting those environments back in sync, getting them getting getting them back aligned.
And let's get back to what we're talking about, like, the revert process.
So maybe the elephant in the room here is that because if you're using a Git based process, you are it's always an additive process. You're always adding new commits. So even a revert is addition of a revert commit into your workflow. So it may it means that rolling forward, fixing forward, fixing to, like, what we what you believe to be the correct states in production across all the other environments to make sure they're aligned, to make sure they're in sync, and to make sure they're working as you expect them to do the thing which is gonna give you the best testing validity and the best quality result.
Amazing. Thanks, Rich.
Mitch, coming back to you as well to cover a bit of a catch all for some of the questions that have been asked here. In terms of Salesforce environment strategy, QA, UAT, etcetera, in your mind, is there one complete strategy that encompasses all basis? And can you give me your take on what level of data should be in those orgs across QA, UAT, production, or any other environments that you might have as well?
Yeah.
I don't I don't think it's possible to say, oh, here is the golden stamp.
This works for everybody. One size fits all model. I would say, though, that generally speaking, use as few environments as you can safely do.
The less environments that you have, it's just the less things you need to manage in your pipeline, and it just makes everybody's lives easier to, you know, decrease that that drift and reconcile differences across state, for each one of these environments. So, you know, the simplest possible workflow that I could imagine would be, like, a shared you know, changes get merged, and they get deployed to a shared QA environment. Then they get promoted to a UAT environment where the business users can make sure everything is working fine, and then you go to then you go to prod. I think that that's about as simple as you can possibly make it, and, keep it as simple as you possibly can at all times.
That's a very core tenet. Regarding, data, data is actually something that's really, really important. Right? Because if you're in UAT, your users are not gonna necessarily know how to create all of these requisite records to be able to make sure that, you know, they can go through the act of creating a contract and, you know, adding some some related records to it.
Right? They're gonna need some, you know, seeded accounts and seeded opportunities and whatever that may be. So I would strongly encourage you to work it within the guidelines of the data governance that you have within your organization at all times. They're gonna know what's best and what's permissible to be replicated out of a production into a non prod environment.
And then there are a whole suite of, data seeding tools and data migration tools. For example, there's a Salesforce, CLI plug in, SFDX, data mover data mover utility, that will, help you to migrate data between environments. I would say in the environments that you're building things in and your initial kind of technical team QA environment, all that you need as far as data is enough to make sure that you have, like, a minimum viable, workflow. In your UAT environments and ones where your nontechnical folks are gonna be there, you need to make sure that you have a high fidelity enough variety of use cases such that teams can come in, and they have maybe twenty separate accounts that they can choose from to create a test opportunity, for example.
So you wanna have, like, enough of a high fidelity where it feels like people are actually in a live system. You wanna make sure mentally they don't have a disconnection, between when when they're testing and what they're looking at in production because that can cause any small disconnection can cause them to become hyperfocused on things and become distracted from the actual features and value that you're trying to deliver. So try to create as high fidelity of an environment as you can with as small of a minimum viable test dataset. And as always, work within work with the data governance team within your organization.
There can be laws, for example, that might, make it sensitive or or perhaps get your organization in a challenging in challenging spot if you were to copy data from production into a non nonproduction environment. So always work with the data governance team within your organization to make sure that you understand what is permissible, keep things as simple as they possibly can be both from an environment strategy as well as from a data strategy as well.
Mitch, wonderful. Thank you. We're coming up to the the close of the webinar here. We've had a very jam packed thirty minutes. But, Richard, I'm gonna throw the question to you first and the same question to you as as well, Mitch. What's the one piece of advice that you have for a Salesforce team to consider when it comes to branching, when it comes to Get Flow, or their process in general in two sentences?
I'd say you understand what the dynamics of your team look like, who controls the parts of production, what what influences, what can move to production at different times. Because that then tells you the level of when that gift will need to get stopped at the UAT environment or or when you might need to make some late changes. I think that that is one of the key things which will help determine whether feature independence or is the right way. Yeah.
Mitch?
Alright. I forgive me. I might spill over the two sentence limit here. But I just wanna let everybody on the on the phone know that the operational model in which your team builds and deploys changes is foundational to the business success that you, of the unit that you are that you are working to support.
Okay? The way in which developers work and the governance product, governance processes that you put into place can help prevent your organization from having a multimillion dollar lawsuit on their hands. And I say that as if it were hyperbole, but it's not. Right?
I've seen Salesforce developments go horribly wrong where, for example, the organization wide default on cases was changed from private to public read, and everybody could see everybody's cases. You do not want to have your organization be in a situation where a journalist might wanna write some some bad things about how you're handling data and what your processes look like. So investing in these things up front, will actually is a is a long term investment in the success of the business units that you all support. And I want you to if if there's anything you could take away from today's discussion or any other discussion you have in this in this space, it's that these processes and these governance and these things about engineering maturity are all things that actually help the business in the long run.
They help the business to satisfy the needs of their customers, to take care of their stakeholders, because you all understand you're building that basic level of trust and foundation in the systems that these folks use to run their businesses. That is the key message that I would like everybody to take away from today.
Sage advice indeed, Mitch. And where can folks reach out to you for any questions, comments, or if they wanna learn more about what you're doing at Salesforce and how Salesforce might be able to support them?
Yeah. Reach out to me on LinkedIn. It's a very great place. Otherwise, feel free to shoot me an email. It's m spano at salesforce dot com. I'll put it here in chat.
Richard, and for anybody looking to find out more about Gearset's offerings or maybe even transitioning from feature independence to Getflow, where can they reach you?
Yeah. They can so you can reach out on so the gooset dot com slash pipelines to find out more information about about the solution. You can find me or either find me on LinkedIn or get in touch with me at richard dot owen at gearset dot com. I'll also drop it in the chat, and happy to answer any questions.
Perfect. Richard, Mitch, thank you both so much for your wisdom, your time, your energy, and your continued commitment to uplifting this ecosystem with all the knowledge that you have and and distributing that effectively through webinars like this. It is much appreciated. For everybody that's tuned in, thank you for tuning in, and I hope you got a lot of value out of this.
Maybe maybe some of you are sitting with more questions than you originally came in with. I know I am for sure, and Mitch is getting a phone call in about five minutes. So so thank you all, and we will catch you again for another product launch sometime very soon. Keep your eyes out for details of that.
And once again, thank you, Richard and Mitch.
Thank you very much.
