Taking Control of Complex Orgs Summit

As Salesforce orgs accumulate complexity, every new project is riskier and more difficult to deliver. In an agentic landscape, questions of org health and control are more pressing than ever.

Join industry leaders addressing org complexity, the impact of AI, and what it takes to make your org ready for whatever the business needs next.

Keynote: The complexity crisis: Ensuring legacy orgs are delivering value

Miriam McCabe, Senior Director, Architect Evangelism, Salesforce

Jack McCurdy, DevOps Advocate, Gearset

Panel: Speed, security & governance in the AI era

Agnieszka Oliver, Salesforce and Mulesoft Platform Lead, Zurich Insurance

Aramayis Kageorgis, Engineering Manager (COE), A Major Media Company

Alex Louderback, Salesforce DevOps Engineer, National Philanthropic Trust

Jack McCurdy, DevOps Advocate, Gearset

Bring visibility, stability & control to your Salesforce org

Andy Barrick, DevOps Architect, Gearset

You don’t have to start over: Lessons from a legacy org

Analissa Moreno, Salesforce Release Engineer

What control looks like in practice with Gearset

Alister McGrath, Senior Sales Engineer, Gearset

Welcome to Gearset's virtual summit. It is nice to see you all.

So many people flooding in right at the top of the hour.

It is great to see you all. It is great to be here. Thank you so much for taking the time to spend a little bit of your day with us wherever you are tuning in from. This is Gearset Summit taking control of complex orgs. My name is Jack McCurdy. I'm gonna be, your primary host for today's proceedings. It's a pleasure to be here and a pleasure to welcome you all in.

But with with my clock where it stands, I think it's about time that we get this show on the road. So, I'd like to take the opportunity to, welcome Miriam McKay. She is senior director of architect evangelism at Salesforce to join me for this keynote. And we're gonna be talking about, the complexity crisis and ensuring legacy orgs are delivering value. Miriam, hello. Welcome to, the Gearsets Virtual Summit.

Hi, Jack. Thanks for having me, and hi, everyone. It's good to see so many of you, connecting.

Absolutely. Absolutely. We got a really big crowd crowd in today, and, Miriam and I have the opportunity and and the job today, to set the scene a little bit for some of the other discussions that our wonderful speakers and our panel are going to be discussing today. So I wanted to take this opportunity to talk about, org complexity and what it means and look at some of the first and initial steps and some of the solutions that might be to the org complexity crisis.

But a good place to start, think, is a little bit of a story about where we are in the Salesforce ecosystem and address how many teams are feeling. And I'm sure this is a major a major or a very common thing that many of us in the roles that we have looking after Salesforce in our organization organizations face. So we have a new major Salesforce project. We're really excited and we really wanna dive into that project, sink our teeth into it.

These days, that might be an agent force project if you are working towards that. It might be something like field service. Back in the day, this was your lightning migration. We have a new project that we wanna get started in.

We're really excited. We're really optimistic about it.

But shortly after discovering, discovering that we have this project, being excited to sink our teeth into it, our orgs can prevent us from making the initial progress and really slow down our optimism about the project that we're gonna be facing. And one of those main reasons is because our Salesforce orgs are complex.

They can be quite challenging to figure out what is happening in our orgs. And the project that you were really excited about and really, really looking forward to getting getting stuck into and delivering some amazing new things for our users, our orgs have gotten our way. We discover our orgs has a lot of moving parts, a lot of different pieces, and what we're looking to implement is gonna touch multiple parts of our orgs. And that org and that complex org that we have becomes that first big technical barrier to us adopting a new feature, a new functionality, or a new cloud. And that naturally leads to frustration. I know that I've certainly been frustrated even playing around in my dev orgs, that I use and that I play with and test out some Salesforce functionality. And those are just dev works that I've just played in.

The problem is then that the projects that we have been looking to do, whether that's agent force or or other big, other big project, field service examples isn't one that I cannot see come up quite regularly or if that's agent force revenue management, whatever it might be. Our business is yearning for us to provide more value with our Salesforce investment.

And because our orgs are a labyrinth and because our projects are harder to get started than we initially perceived, there is a delay back to the business and to our Salesforce users. Are expecting us to deliver features and functionality that are gonna be delivering a lot of value. And this isn't great for the business. It causes frustration.

And for many of us, we want to be in our roles. We joined the Salesforce ecosystem. We have Salesforce jobs because we're really passionate about creating great user experiences. And it can be can be a real challenge when our own orgs, the Salesforce orgs that we're working in, are is the thing that is getting in the way of us being able to do that.

We don't want you to be fed up. And this is what we're gonna be talking about and exploring today is how can we solve this challenge of org complexity and how can we move forward so that we're able to deliver that value that we need as quickly as possible to the business that are asking for it?

So I think it's important to actually dissect what do we mean by complex orgs, and why do our orgs get complex in the first place. And that's where Miriam's gonna start help helping me out a little bit when we're going through complex orgs. But we've three main areas here, to highlight some of some of why orgs become complex and what we mean when we say complex orgs.

One of these first areas is when we have limited governance and data hygiene. Data hygiene is a topic that is old rage at the moment, you know, good AI solutions that we are introducing to our enterprises relying on good, clean data. But quite often, Salesforce orgs come with limited documentation. You might have been working on your Salesforce instance for, I don't know, maybe, maybe a year, maybe even three, four, five years in some instances. And the lack of documentation, why things were built the way that they were built, and what those features and functionality are for is often very lost in translation. So combining that with the data cleanliness and fields that are no longer used or maintained, can create a web of issues. Install your progress as your org gets bigger and more complex over time.

We also have a affinity for high levels of automation in our Salesforce orgs. There are flows, Apex classes, that do a plethora of things across our Salesforce environments. And high levels of automation that's for multiple objects, think about if you, save a record, for example, and that triggers one automation, that might be fine. In some orgs, in larger orgs, you may find that multiple automations fire when a record is saved, and that level of automation increases complexity.

And automation that touches multiple objects across multiple clouds creates risk. The changes that we are looking to introduce may break some other automation or some other process that a business elsewhere relies on.

And finally, if you are in a Salesforce implementation that has multiple clouds, business processes, and multiple teams, that larger Salesforce footprint is going to introduce complexity as well. If you have a team looking after Sales Cloud, if you have a team looking after Service Cloud or any other Salesforce products, then coordinating your work across multiple teams, multiple business process, and multiple work streams introduces complexity as well as those teams like to work in different ways.

Miriam, is this resonating with you and what you're seeing with, complexity in Salesforce teams?

Yes. Absolutely. I think oh, well, I'd be interested to to hear from from the audience if there is anybody in in who doesn't recognize all of these items. Right?

There's so many dimensions and aspects to complexity. So the only the the one thing that I would maybe add is having high complexity or having complex orgs is not necessarily bad either. Right? So so a lot of automation is also a good thing.

It is also something that adds value for end users. And because we service complex businesses with complicated processes or loads of processes, loads of end users, etcetera, load lots of data, it's almost also inevitable to have some level of complexity in there. Right? So that is not necessarily bad, but the consequences of it can be bad.

And that I that I think is what we'll be talking about throughout this summit some more. So I'll leave it with that. But, yes, fully aligned with what you put here.

Absolutely. Absolutely.

The important thing is that this complexity, it doesn't grow in a straight line. It's not a straight up, you know, graph to the right. The complexity grows at the same speed over time. The more that you introduce the complexity of your orgs compound with each new feature, functionality, business process that you look to do, then the org becomes more complex, and the org becomes trickier to figure out when we are looking to implement new things and do those things.

So it's important to realize just because it's been a year, you cannot predict that just because your org is x amount of years old or x amount of days old, that that complexity is just going to increase in a linear fashion. It all depends about what we're doing and what we're implementing into our orgs. You may find that you have an org that is a year old and is already become quite complex. You might find that you have an org that is five years old and is less complex than maybe the ones that are a year old.

So it's all about what we're introducing and how we are introducing it, which brings me to the next point of why we need to solve the complex org challenges that we have.

And the first one naturally that leads on quite nicely is the scalability. So what we need in the future is likely to be bigger and better.

And complexity can get in the way of us being able to scale our business processes. If we are looking to take on more Salesforce products or increase our usage of Salesforce products, then we need to make sure that our orgs are in the healthiest, position that they can be so that we can increase, our level of investment in the platform and continue delivering value to our users.

The big one, which I'm sure a lot of us are excited to hear about and the important thing or usually the most important thing that I hear people trying to figure out these days is AI initiatives. So for our AI to succeed, I already mentioned data. I already mentioned, the complexity of having data that might be out of date, objects that don't or might not be quite fit for purpose in the AI, era that we are stepping into. So your AI cannot excel in complex orgs. Our AI needs clarity and cohesion so it can deliver that value. Whether you're using AI for, for your coding practices or your development progress, if you're using, Claude or other platforms for your code generation or configuration generation or you're using agents themselves as part of agent force, then your AI is gonna need to have a clear vision of what your org is and allow you to deliver that value, to your users through those initiatives.

And then lastly, with complex orgs, if it is not clear to the users what is happening in your orgs when those automations are firing, for example, something that we've talked about already, Those complex orgs can limit the adoption of our new features. There are obviously other issues that impact, impact adoption of new Salesforce features and functionality, of course. But the more complex an org is, the likelihood it is that increases that users are gonna find workarounds to dealing with our complex Salesforce environment. They're gonna go and have an offshoot and have a process that you might not know about. And as Salesforce is a tier one business application that we look after, we wanna make sure that our users are being serviced in the best way, and we have a record of our all important custom data moving forward.

We don't want complexity to introduce those workarounds.

Miriam, is there anything else that I haven't said that you're you're saying as well?

Yeah. Yeah. I mean, the the one another way to kind of summarize all of this is or the way that I like to summarize all of this is that, like, change is the only constant. Right?

Like, we're not going to unless maybe we're getting very close to the end. Right? We're not gonna have a situation where there's not going to be any any changes. And so having said that, the the one thing that I wanna add to this is why not also.

Right? Like, we we can address it, and and it's easier now than it's ever been. So we have all this tooling. They're set.

It is an example. Right? But there is all these AI assisted ways now that we can look into our org, understand what's going on. And so it used to be maybe that it took more work and effort to to address it, and now it's easier.

And that allows you then to invest more in in your people and have the people think about the next best evolution of your org or of your automations or whatever it is, your a AI initiatives rather than having to spend their time working around the complexities. Right? So that's the one thing that I would add.

Yeah. No. I wholeheartedly agree. Anybody that has listened to me talk at an event or a webinar before has talked quite a lot quite at length about people and how we bring people into actually solving the things that we need people to solve them for and do the deep thinking about, where we should take our take our orgs and how we can best serve our users. So I absolutely and totally agree.

And as an aside, so for, the sources of this for for this survey, but for every dollar spent on development of code, it can cost roughly six dollars to fix or remove that technical debt later. So with our complex orgs, if we're able to get our orgs back into a good state and be able to think considerately about where we are gonna be taking our organ on that journey, then we have the opportunity to save not only our time and personal frustration through fixing it, but make better decisions that are gonna financially resonate with our businesses as well. So this is the concept of shift left, and you'll be able to be able to make, sound investments, for the future here as well. But before we go and jump into talking about some of the ways that we might be able to solve this at the end, which Miriam is gonna walk us through, we're gonna come back to our little cartoon. So the project can't go anywhere in the business value is stalling. We're just fed up.

Let's have a collective mindset that we can fix this together. We can fix this with our teams. If you are a leader in your organizations for your Salesforce implementations or a leader in your organization generally, let's think about how we can fix this together. Let's take the initiative to solve these challenges so that we as a team are able to work cohesively and coherently towards delivering that value that we all wanna deliver. It's the biggest thing when I travel to events, when I'm speaking to folks in the ecosystem is we want to drive value. We wanna do the cool things. We wanna do the things that are really gonna make our users happy.

And to do that, we need to work together to do it. And if you're a leader in your organization, I implore you to take that mantle and take ownership of solving some of these things.

I'm gonna throw this over to Miriam.

With all of her experience in the Well Architected Framework and Well Architected program, program that I advocate for wholeheartedly, Miriam, what's your advice for how to get control back of our orgs?

Yes. And, of course, like, I'm not going to give you, like, three bullet points and then we're done. Right? But what I will try to do is set up some some ways to kind of categorize all the sessions that we're going to be looking at as part of this this summit.

But before I ask you to click, Jack, I I I want to really emphasize this point that for me, it all starts with also embracing this idea that complexity is going to be there. Right? Business is complex. Your org is also going to have some level of complexity, and that is okay.

Right? The goal is not necessary to have a simple org, but the goal, I think, is to be able to deliver the value to the business.

And so doing that and and control having control is one of the the ways that we we can do that. Right? So that's how I would like to frame the rest of of these slides. And the way that I've organized these three buckets, and let's start with the first one here, is almost chronological. Right? So it could start with prevention. Let's say in an ideal world, it would start with prevention.

So if we cannot prevent complexity from happening, what we can do is put in place the necessarily be the necessary behaviors and processes to stop it from actually occurring in the first place. Right? And the hook with what's going to follow is that governance is going to be one of those topics, which is going to be covered in the in the panel, and that obviously plays a big part in that. And, yes, there are also resources as part of the Salesforce architecture program of the architecture center that can help governance bodies and architects make the right decisions when they're designing to help prevent unnecessary complexity.

Right? And then the next one is detection. So let's say we were not able to prevent it for some reason. It's it's happened.

Right? Maybe we inherited an org or just some other reason why we have complexity in there that we want to control or understand. And that that is then when we when we get into this angle of detection. And there is a talk also as part of the summit, is about gaining visibility and control. And so this is about the visibility aspect of that. Right? So step one is obviously understanding what you have.

And then from a Salesforce architecture resource perspective, for example, there's patterns and antipatterns that are made explicit that you can then use to detect. And then, of course, last but not least, remediation.

And the reason or or I'm highlighting intentional here because that's part of the well architected behaviors highlighted in the well architected framework, and that is obviously, you need to have some level of intention to then, once you have detected it, to do something about it. Right? And I'm and I'm sure that Jack is going to have something to say about that maybe now as I hand it back to you, but also as part of your session later on how to use your set to take control of org complexity.

And I also think that Anna's session on less lessons from a legacy org is likely to touch on this too.

So back over to you, Jack.

Thank you, Miriam. Yeah. Absolutely. And it's it's such such sound sound advice. You know? If you can't do one, do the other.

And if you can't do that, then there's always always something next. And I really like what you said about intention because intention is the core of everything that we do on on the Salesforce platform or every interaction that we have with people across the business. It come with a good intent and come with the commitment to make the decisions and do the things that are gonna improve our users and our relationships across our organizations when we are looking to deliver them solutions, whether that be the simple simple quote unquote Salesforce solution that's required or whether we're taking on larger AI initiatives.

How do we get the value? What is the intention behind what we're doing? And how can we make sure that everything that we are doing is tied back to a better human experience? So, absolutely absolutely resonate with, the intentional side, of that.

Indeed. Indeed. We have some useful resources. So we have a whole, a whole afternoon here, a whole couple of hours left that where we're gonna be exploring some of these topics in a little bit more detail.

But useful resources that you might want to look at here, if you are sticking around until the end of the summit, my colleague, Ali, is going to be doing a little ten minute intro about how some of the Gearset's products and, the Gearset platform can help you solve some of these challenges, but there's a QR code here if you wanna skip ahead. And for the Salesforce Well Architected Framework, there's a QR code here as well. I highly recommend that everybody takes a look at the Well Architected Framework and works with that architect mindset when approaching the org complexity challenges that we have.

And for the other, for the other sessions that we have coming up, we're gonna have some real life insight into how these challenges can be solved as well.

Miriam, thank you so much for your time and your experience and your expertise. It is it is highly valuable. Will you be sticking around in the chat for a little while here, or do we have to bounce off, and where can I direct people to if they wanna learn more about Well Architected program frameworks or catch you and your colleagues at other events?

Yeah. All of the above. So I'll I'll stick around for a bit, and and then you can we we try to be at community events where whenever possible as part of the architecture program, my evangelist colleagues, but also you could catch us on LinkedIn and our YouTube channel.

And then, also, there's the Salesforce architecture center, which has the the well architected framework and a lot more. And don't forget the blog. So it's plenty of there. Plenty of opportunities.

Plenty of places. And and you mentioned the community events as well. The Salesforce community events are so important to us as a Salesforce ecosystem. So I encourage if you are able to attend Salesforce community conferences, then please do so.

It looks like I have messed up in the slides because this wouldn't be a Jack McCurdy presentation without one small error, and the links aren't working. But, hopefully, one of, one of my colleagues behind the scenes can drop those in for me. And Rachel has. So thank you so much, Rachel.

I appreciate that.

Thank you for listening, to the opening keynote. Hopefully, as that set the scene and set the tone for some of the things that we're gonna be talking about here over the rest of the summit. And, Miriam, thank you once again for your time and expertise.

Wonderful.

Okay. So in just a few moments' time, we are going to be jumping into a panel with that q and a that I mentioned at the start of the webinar. So, this is your opportunity as we are talking here to get our panelists insights into, how they are handling, some of the complexities in governing our orgs in the AI era. I'm gonna be joined by an absolutely fantastic host of Salesforce professionals.

So we have Aga Oliver, who is the Salesforce and MuleSoft platform lead at Zurich Insurance. We've got Aram Khayorjas as well who is the engineering manager for Salesforce Center of Excellence at a major media company and the founder of his own, ISV company as well. And, of course, joined by Alex Lauterbach as well who is Salesforce DevOps engineer at the National Philanthropic Trust. And with me, you're gonna have to listen to me a little bit more as well, for I am your host, but hopefully not doing, all that much speaking.

So when our folks are ready, they will join me in here, and we will kick off our our panel session.

Hi, Aga. Hi, Alex.

Hello, everyone.

Hello. Thanks for having me.

Absolutely.

And we have lot Ram as well.

Amazing. Thank you for thank you for joining me, folks. It is a it is a pleasure to to have you here.

Speed, security, and governance in the AI era.

Important topic. Everybody is talking about AI at the moment, how they can make best use of AI, or complexity.

Obviously, one of the areas that we are looking to solve and looking to challenge. So, we've got some questions, lined up for for you all to to have a stab at answering. And, hopefully, our audience here have got some questions for us as well, which we will undoubtedly get to.

But to to kick us off, to kick us off, Aga, I'd like to come come to you. So from our perspective, like, a lot of the AI agents in the promise depends on clean, well governed Salesforce orgs. But what's your perspective, and what's your take on whether most Salesforce orgs are actually ready for this or not?

I don't know how many of the people are having a luxury of working with the new orgs, probably not many. So my take is that many of the people will have to work with the legacy org as Miriam has mentioned that the complexity is there. So I think for me, the org will be as ready as we are, and it really depends on your mindset and how you're gonna approach it. I think people will be trying to manage the technical debt, have the perfect use cases, have a perfect data, have everything perfect, but reality is that the world will never be perfect. So so for me, it's more about starting small and then moving from from there. And I think the most important is to have the basics right. So we at Zurich, we are really keen on making sure that DevOps life cycle is well governed, and we know what we're doing before we can start introducing much more complex processes as well.

Yeah. No. Absolutely. Start start small and start small and see where you can get to afterwards. Totally concur. Aram, I'm interested in your take on this question as well because working as part of a center of excellence in an organization that has a a large number of Salesforce implementations across the business. What's what's your perspective?

Yeah. I mean, I I would totally agree with that. Like, the basics need to be in place.

So just just kinda going back to what what we were saying earlier, you know, for me, the controls haven't changed much since the pre AI days.

I almost always use the same same controls that I was using before.

So for example, like, you know, the policy that we had before is to give a dev, basically, as much access as they need in dev sandbox to do whatever they want. But if they if they wanna go beyond that and not just in production environment, but even in shared testing environments, user permissions need to be audited.

So, like, you know, everyone shouldn't be a system admin or even have admin level permissions.

You know? In that case, you know, principle of least privilege should be followed.

And in if if if it is, then, you know, any metadata change that's to be promoted is forced to go through the deployment pipeline.

So it's really important to have, you know, like, a robust deployment pipeline in place, whether that's through the assistance of a tool like Gearset, which is a solid tool, or even having, like, your version control management and version control system in place and kind of, like, a solid branch strategy in place, that that's kind of, like, the baseline, I think, to to kind of have this to to have controlled promotion of of changes.

You know, I think more or less, AI, you know, hasn't changed the way we do things. It has just exposed gaps in our release management process because the volume of code that AI generates, you know, we're deploying a lot more. So it just kind of, exposes gaps in our lease management process, I think. So, you know, having the basics in place, would completely agree with Aga's point, is really important.

Yeah. For sure. I I totally agree. You know? But the one of the things that we talk about Gearset a lot is you need to have those robust controls in place if you're gonna make use of all the tooling, the new tooling that is available to us and, your point about exposing gaps.

Absolutely. And, Alex, you've been you spent a long time, you and I have known each other for for the better part of two years now, as well. You've been on a great DevOps journey there at MPT. From your perspective, how, if if at all, has AI changed the governance conversation in Salesforce teams over the last twelve months or so as you've been on this journey?

Yeah. Absolutely. It really raises the criticality of governance. Right? Kai I kinda wanna echo what my colleagues have said that the conversations are similar to what we had of, you know, maybe in the the first year of our DevOps journey, which was twenty twenty five.

The conversations are really similar. It's what gates do we have in our CICD pipeline? You know, how do we recover from a change failure? Except now because change is happening so much quicker, it's become way more critical.

Right? So having a human in the loop is really the one conversation that's changed. It's every single AI tool that we implement or every single, you know, gate that we have. It's after the AI makes a change, how do we have a human review that change before it just goes right to production?

But outside that, it's you know, we were talking about, we were talking about how to recover from a change failure last year, and now it's just way more critical because what if AI causes the change failure? How quickly, you know, Dora metrics and mean time to recover and things like that are are really top of mind for our team right now amongst many other things.

Yeah. And to to follow on off the back of that, how has AI tooling changed, like, the threat model at all? Like, are you worried about different security risks than you might have been two years ago, eighteen months ago?

Absolutely. And I think you've seen a huge emphasis from Salesforce themselves on this. The summer twenty six or so summer twenty six release has been extremely focused on IDP controls and various login methods, methodologies. We've been able to implement some of our own AI testing of just penetration testing. We're lucky enough to not have a digital experience that we operate at MPT that's outward facing, but I know a lot of my colleagues at other organizations that have an external facing website have seen a huge uptick in the risk.

But AI, at the same time, as it proposes a lot more risks, it poses way more opportunity really in that threat modeling. The testing capabilities of AI are very robust, and good organizations are tapping into that and and utilizing that.

And, Jack, if I may add just as a Alex perspective, you have the external threats that we know the security is being tightened up, but also you have a internal. So are our teams ready to manage and bring AI? Do we know how to do prompt engineering? Do we know how to set up the right security?

Do we know the the language models you wanna use? Do we talk about the hallucination? Do we have the right governance in place to keep controlling what the agents are doing? I think all of it can bring the the security concerns as well, so it should not be only looked from external, but also internal view.

And I think this is a big shift as well where people need to take more accountability of it, and everyone who works on it is responsible for security rather than just the architect in the past at the very beginning for designing a solution. Right? Now everyone from the beginning until the end in our organization has a responsibility of making sure we sound and safe.

Oh, absolutely. Absolutely. Aram, have you sit have you have you seen much change to the governance conversation, across your company, over the last twelve to eighteen months? I know you mentioned the the principles of least privilege and the good security practices that most Salesforce organizations should should be following as it is anyway, but interested in your take there as well.

Yeah. Yeah, Jack. So I think one of the biggest mindset shifts we've made is moving the conversation from should we build this to should we own this in production.

So, like, anyone could build a a prototype over the weekend. That's easy. AI lets people move much faster.

So the bottleneck is no longer creating Apex or AWCs.

The bottleneck becomes architecture, security, testing, ownership, and long term support.

So in that regard, I mean, like, I always like to go back to the the DevOps principle of that long predates AI and cogen.

You build it, you run it, or how I like to say is you build it, you own it.

And the reason why I like to make that tweak at the end is the person who builds it, I don't always expect to run it themselves, but they should be able to articulate what ownership and production will look like, and more importantly, what ownership will in production will cost before they decide to move forward with their AI generated app.

So I found that that kind of mentality, it fosters this end to end accountability.

I mean, that like, AI, as as amazing as it is, it hasn't changed that. Right? Responsibility still needs to be owned by a person. Yeah.

Okay. Accountability and ownership, I think, is one of one of those big things. If AI is generating our code for us or if, it's an AI implementation, who who actually owns that ending up in production and what the impact is going to have. And I think that's one of the changing roles that admins and developers and architects, have hopefully more visibility into is if this thing is gonna be shipped, are we gonna be wholly responsible for it?

We can't just pull enough AI built it. It was AI's problem and AI's AI's AI's thing to sort out. We're the ones responsible for putting it there and therefore owning whatever consequences, both good and bad, that come out of it being shipped. There's a couple of really nice questions here, that have come in through the q and a.

So thank you, to the folks for for populating us. And I'll throw I'll throw this one, out to the panel.

Tracy's asked a question, what would you recommend for the governance process for multiple teams of admins who rolled up from different departments and making changes to one org?

Curious to curious to hear the panel's take on on that.

I can start. We went back to basics. We have a release team, who's centralizing, what is happening in the org. So very often, you may have a multiple teams working in a in a in a one org at the same time, but you need to have some sort of a governance to say, this is where I'm going.

This is the changes I'm doing. You need to have a robust testing process as well and the branching strategy so you can control and manage as well. But it doesn't only start at the after development. It also starts at the requirement phase and alignment a little bit.

So I I think it's more about bringing people on board, what changes are happening, understanding is there an overlap, is there gonna be any potential of a regression, aligning to change before development, and then controlling it through the pipelines as well.

Yeah. Just to kinda emphasize that point there, really, I I think having people test changes in sandbox and scratch orgs if you're not already. You know, not every I I think the latest state of DevOps report showed that it's better than ever that most people are using scratch orgs at this point or or sandbox orgs, one or the other. But having that as the step one, if we're specifically talking about, you know, multiple admins making changes, go how to go through some sort of test phase first.

One part of governance, we we've said pipelines a bunch of times and something that else that my team has found very successful is we implemented a static code analysis tool with GearSets code reviews last year. And it's kinda funny watching that go toe to toe with some of the AI agent work as well is very funny. Like, it'll like, the AI agent that we've been using for building will make a change and then make a pull request, and then the static code analysis will flag it and say, you it has this vulnerability, this vulnerability, this vulnerability, and then kicks it back.

And watch that go back and forth, you know, ten, fifteen times. It has been very interesting to watch. I'm sure in the future, would like to see this, like, more optimized where AI just gets it right from the get go and has security built in mind. But just in general right now, I don't think that industry is is quite there yet.

There's still serious, we've all seen the headlines of serious security concerns with all of these co coding tools. So don't lower your standards just because you're building quicker. Still have your static code analysis tools, still have your sandboxes, your scratch orgs, every other tool that you use to validate that a change will be successful before it hits a production environment. I think that's going to be critical.

Yeah. I guess a question off the back of that as well, Alex, and and for the rest of the panel is should AI generated code or configuration be reviewed any differently from if an admin or developer wrote it?

At the moment, I don't think so. I mean, in in in our world at the moment, we really encourage people to use AI tools to enhance their day to day work, but it doesn't mean that that code is looked at any other way than as if the developer will submit it for the review. So developer is using AI tools, but it's their responsibility. It is their work in the end.

They they click submit. But who knows what's gonna happen in the future? I think the tools are evolving, and we're gonna be evolving. And there'll be change management, and there'll be a bigger trust and capability.

So I think for us at the moment, no. It should be the same reviews, sometimes even deeper because you have to learn to trust what is being generated or learn to to prompt properly. So it depends on also the maturity of the team.

For I would like to just add a little bit to that that it really does depend on the maturity of the team. And if you are not if you do not have really good review pipelines set up, then it should be scrutinized more. Right? It should definitely not scrutinize less, specifically AI generated code. So if you're not already doing peer reviews, my team, we have documentation on what kind of metadata changes gets peer reviewed, what gets business reviewed, what, you know, needs security review from a sec outside security team. If you don't have those kind of things set up, you probably should be doing that for a hundred percent of AI generated code already before determining what needs, you know, more specific reviews. So if anything, Jack, it needs to be even more heavily scrutinized because there are lots of hallucinations, lots of security risks, lots of errors.

At the same time, it can really speed up your workflow.

Yeah. And just to add to that, I I completely agree. Like, AI generated code needs to be more scrutinized than than, you know, not AI generated code.

But from my experience, like, the technical debt increases when developers fully offload their decision making power to the AI, design design decisions, security decisions. For me, that's really dangerous. You know, for example, if Codex incorporates some sort of library and then it introduced, like, a huge dependency on a library for your app. Let's say in a few months, your library needs to be updated or even retired.

That same developer who blindly had AI generate that code can't explain why that library is being used in the first place. Right? And that's that's really dangerous because now that that developer needs to deal with that issue while the entire application is down in production. Right? A lot of downtime.

So I guess I don't know. To sum it up, like, I I would say the danger isn't AI writing that bad code. It's letting organizations accept code that they don't fully understand. I think I think that's the the danger of not, like, reviewing code with a lot of scrutiny reviewing AI generated code with a lot of scrutiny.

Right. Yeah. And that really highlights Jack's quote from earlier, that one dollar spent on development cost six dollars to rework or remove later. I mean, it just is so critical.

Yeah. Yeah. I think I think what's That that's a good metric, Jack. Yeah. Yeah.

Thank you. That's I think that's interesting because you Aram, because you were talking about accountability earlier. Like, who owns the thing in production and how do we make sure that if we are using AI tooling to help generate code and config, then who's gonna own that and what does that look like afterwards and and those considerations. There's a really interesting question in the q and a as well from, from Michael Johnson. How do you prioritize governance efforts when you have limited resources and time to commit to already to making changes and updates to Salesforce?

And I'm in insurance, a regulated industry. I don't think there is a question of, you know, how much governance we do. We we have to follow the governance process, and that's not because just have to be done. It's about security and making sure we follow the right steps.

So it's a little for for me, it's not about how much time you spent on it, but how much do you know what your governance is, when it will be applicable, and how your changes will impact the governance and what do you need to do about it. So more prework you will do about understanding the the rules, the security, the culture, policy within the organization, but also how the agent force works or how any AI tool works will be much easier than to follow that governance. Bringing people on board is really important. So we've done a lot of internal kind of alignment.

This is what we're trying to do. These are the tools. This is how it works. So we've done the prework before.

And then when we go to have something approved or reviewed, those teams already have the basics knowledge, they just look at the use case, which speeds everything up. So we do not sacrifice the governments for speed. We're just trying to to manage this a little bit different.

Yeah. And and just to add to that, I mean, like, the the scarce resource today isn't developers. It's the people who are actually gonna review the code or at least having a human in the loop to review the code.

So I would say I mean, because AI is saving a lot of time that that would would be spent on development or developers, I feel like it's a shift of responsibility now or or shift of a role that for your existing developers, they should be doing a lot of the reviews. They should be implementing governance and not just be focusing on building things and coding things. Right? I think that's what AI has made more efficient. So I I think it's shifting now the responsibility and the role of these existing developers on your team to having more of a governance role as well.

Yeah. In my view, the bad news is that this conversation has been going on a long time. I think, honestly, this is an extension of the conversation way before AI. It's how do you get your team's suppliers at DevOps? Right? Like, how do you how do you say, we're gonna dedicate time just to look at dev ops? The good news is that I think, honestly, AI kind of materializes the benefits a lot more for teams because instead of just saying, we're gonna invest in our CICD pipeline or we're gonna invest in the SDLC life cycle, now you can point to specific gains that other organizations have experienced from this the speed that AI can deliver.

So my process really stays the same. It's kinda what like I said, identify your cheerleaders, identify your people that understand the DevOps life cycle, look at each phase of the DevOps life cycle, and how can AI help that phase? How can AI help your planning phase? How can it help your build phase? How can I help your test phase and your release and everything else?

And then, you know, bring it to the larger audience once you guys have an established plan of this is how we're going to speed up and better our process, throughout the entire life cycle. I think that's how we got buy in for implementing best DevOps practices three, four years ago, and I think that's how we're getting buy in now from implementing various AI functionality throughout the SDLC.

Absolutely. So Yeah.

And I I just wanna add oh, sorry to interrupt, Jack.

No. Go ahead.

Just I I just wanted to quickly add to that. So, you know, like, what you're saying about how this is something that even before AI, it was hard to get buy in.

You know, we we've seen this movie before. Right? Like, you know, Salesforce always had this promise of empowering business users with no code, low code development, you know, similar to what AI is doing now. Right? Like, just it levels the playing field. Any business user can now build their own apps.

And even back then, like, what what did we see? You know, engineers weren't replaced.

It I I think it just changed their focus. Right? They became their role and, you know, kind of what they do on a day to day basis changed. So I think AI is doing the same, and the scarce skill is shifting from typing code manually typing code to, you know, making sound architecture calls, enforcing guardrails, then owning the outcome at the end of the day.

And can I just add? I love what Miriam said at the beginning. The only thing is that this constant is change. Right?

So this is really highly changing environment at the moment when we can see, you know, development of AI capabilities every single month. Our org complexity is not gonna go away. But what needs to happen is changing people mindset and the skills, whereas we've discussed previously, developers will no longer be purely responsible just for coding, but maybe for architecting it more. So there is a big shift of what is the future of the skills that the people will need to have and how they will use those skills and AI tools to to enhance delivery for the business.

Because as you mentioned, Jack, at the beginning, everyone wants to add the value, right, to our business teams.

Yeah. For sure. And something I'm really curious on all of your takes on is, like, the the human role and how people are feeling about this shift right now. Because for for me, being out in the community as as much as I am, there's there's various takes on, whether where we're going in the direction that that we are traveling. And some and, Aga, I'm gonna stick stick with you for for the first stab stab at this question. But those human skills and the as roles are transforming in this new AI forward kind of era, what to you is kind of the essential human capabilities and the human skills that you employ your team to invest in when looking after Salesforce and, obviously, delivering that value to the users?

Yeah. I think for me, in general, whether this is AI or not, is being curious, asking questions, and thinking about the future and what what makes sense and what doesn't. So I don't see AI as a replacing the team. I see AI as enhancing the team as well, but the team also needs to take responsibility that the that the skills will be changing.

Right? The AI gives us a possibility of doing more work because suddenly we don't have to have the core skills. Our admins, what we can see internally, that they don't rely as heavily on the devs to understand what's happening in those complex orgs. They can go to AI assisted tools, type few prompts, and they will have all of the explanations as well.

So I think the accountability needs to be on the leadership level as well to push for the skills for the future, for the curiosity, for the right architecture and design, rather than just with the with the individuals.

Great advice.

Alex?

Yeah. Sorry. I think my connection broke up for a brief second there. But one thing that I've seen our developers shift more and more to is on the prototyping and design phase of technical capabilities. So if we can quickly generate a prototype versus before, maybe it was just listing technical requirements of a of a Jira ticket.

Before maybe two, three years ago, that required maybe a designer. It required, you know, knowledge and a tool like Figma.

We've been prototyping more and more, even the most minor changes.

Even something as simple as just taking a screenshot of the existing page and showing what the design will look like after the update. Like, I take the screenshot, put it into Claude, and and show that to the product owner or the stakeholder or somebody else. That has incredibly just gotten everyone more aligned from end to end and shifted that shifted that entire process left versus something being built in a sandbox even.

After that, especially, if it gets to a test environment and, you know, a change comes back and says, well, we actually wanted it this way. That's a huge waste of time for everybody. If we can all get aligned earlier and earlier and, you know, it it saves everyone so much time and and value. And then the the main benefit is that, you know, at the end of the entire process, everyone is just more aligned from before it even hits the sandbox. We all know what the end vision's gonna be and what it's gonna look like in production. So AI has just really revolutionized that for our teams.

Great. Thanks.

I'm throwing it back to the throwing it back to to the q and a. I'm gonna actually combine a question from from the q and a and and the chat here as well.

And, potentially, Alex, you might wanna take the lead on this. I'm sure you have opinions, TM.

For an org around eight hundred users and six to eight admins, would you recommend the deployment of releases managed by one person, I e, a release manager or DevOps engineer like yourself, or open to all admins and devs? And then combining that with another question from the chat, could you touch on your experience with multiple teams developing and supporting different applications under the same org in terms of developer experience? So I think those two questions are quite closely aligned from my perspective.

Yeah. Yeah. I can take the first stab at this. Release management and ownership over the org in general are owned by your entire admin slash developer team depending on how you define your That's not to say that you don't have one person taking point and leading the release.

But in our instance, just to give a very hyper specific example that works for exclusively us, You know, me plus one other person, if I'm out of office, will own the releases. They'll build the release through our CICD pipeline through Gearset.

You can own everything no matter what tool you use, though. One person can own it.

But it's up to the individual devs, kinda like what Aram was getting at before that, you know, you you build it, you own it. They have to run the post deployment steps. Now those post deployment steps are documented. They're shared throughout the team before the release.

About one hour before the release, they go out to the team, but they're labeled. They're like, you know, OneDev, you will you'll run this. Stacy, you're gonna run this. Peggy, you're gonna run this.

You know, that's that's how our team operates. Not every team has that flexibility, and that's why I wanted to emphasize that.

So I'm sure some of my other panelists have more thoughts, but for our org, it's kind of a similar org. Yours sounds a little bit larger, the eight hundred.

That's that's how we operate. Other teams might have more constraints where other entire teams own that release process, and then you even have to be more documented. But I guess the central theme of this as I, you know, continue to answer it is just, like, you know, the documentation of the process. Whether it's one person owning it or everyone, everyone's on the same page. Just coordinate as much as possible and plan as much as possible, and everything just gets way smoother.

Alex, can I add to it as well? Because Yeah. I mean, congratulations. You have so many admins for org of eight hundred. Right? I'm very jealous, honestly.

That's the one thing. But but for me, it starts with the ownership on the business side. Right? So all of your admins must be getting those change requests and amendments and innovation from someone in the business.

The question is, is the business aligned of what they're asking your admins to do? Right? So there is a think about our teams, technical teams to be aligned. How do you deliver those changes and pushing them through the pipelines and testing them?

But in the first place, is the business or this different business stakeholders aligned what change they want in the org? Because I come with the stand. I own the platform, but I don't necessarily own the process. So the question is who owns the process?

Who agrees on those changes? And sometimes you do have to make a priority on which order or events is is going. So the question is, do you have a product owner? Do you have multiple product owners?

Should they be talking to each other? Whether they changes are contradicting or working together in which order they should go with. So, you know, be before we move into the technical delivery, just looking at that change on the business side as well, is that coordinated enough and prioritized?

Was that was that a actual question for me, or is that rhetorical?

Because No. No. No. It's just an addition.

Reason I reason I asked that is I think it differs from everyone every single org. In our org, like, yes, we have product owners that are aligned to specific problems, not necessarily Salesforce as a whole, but individual problems and individual teams that our org is trying to solve.

That answer is gonna change from from place to place. And I think just to to, like, bring the question back in just a tad is is, like, just the release management, the release coordination, and how to make sure what you said, like, one change isn't stepping on another change. And the order of changes, that's where it's important to have one person coordinating just the release management perspective of it. And saying, like like, yeah, this product owner is saying we need this on Tuesday, but this product owner is saying we need this Tuesday at four PM.

Staging that and and and organizing that, you need one person just taking point on the release, in in my opinion, at least. If that's a dedicated DevOps person, I think, Jack, you were kinda getting at that since my title is a DevOps engineer. I'm very lucky to have that title. Not everybody has that grace to have a dedicated DevOps engineer, so you could have a release manager or even just your release guru.

But somebody that knows what the release process looks like, plans as much as possible in advance, that's always, like, key to release. Like, our worst releases are the ones that come up last minute, and we need something changed really quick. Our best ones are meticulously planned.

This is the order of deployments we're gonna do. We're gonna after and, especially, we we we're having a little conversation in the chat earlier, but if it requires outside integrations, coordinating with those teams of, you know, we're gonna update Salesforce, but at the exact same time, you're gonna update your, you know, and and just taking ownership, taking point over that, just the release process. I think it's really good to have one person taking point or a small team of people that can, you know, hop on a call and just own that.

That kinda answer that.

Oh, oh, yes. Sorry. Sorry. It's Raj's slide. I was resonating with what what what you're saying, Alex.

So just to add to that, I mean, it really depends from org to org and from company to company because at at certain companies, you have no choice but to to to have a single person in your production environment with admin rights. So, for example, you know, at at, you know, a company that or an org that has really, you know, sensitive data that falls in the SOX categories, you have to follow a certain, you know, kind of controls in place, one of them being segregation of duties. So a person who, you know, changes metadata or, like, a developer who has a developer role can't be the same person who who deploys into the to the production environment.

So so you you I I just wanna echo that point. Like, it really depends on, you know, the the org, the company, what what kind of controls you have in place because a lot of times, you don't have a choice. Right? You get audited.

Your permissions get audited. You see you have you know, all of your devs have admin access in your in your production environment, you know, that's that's a red flag, and you immediately immediately get dinged. Right? So I I, yeah, I just wanted to echo that point.

Like, it really depends on the scale of the orgs. I mean, sometimes if if there is a smaller org, you don't wanna have those really, really robust controls in place because sometimes it's overkill. Right? Like and it ends up being more of a blocker than it is helpful, especially if it's not required.

So, yeah, I just want I wanted to echo that point. I think that was that was really, really solid.

Well and and just to tweak, I guess, make sure one thing doesn't get misconstrued.

Like, what I was trying to say as well is not it's not necessarily that you're the one clicking the deploy button on every single change in your org. Like, I'm the DevOps engineer, but I'm definitely not doing that. There's plenty of changes. All that goes through our CICD pipeline, but there's changes that happen from multiple teams inside of our CICD pipeline.

It's more just having one person coordinate it on the, you know, coordination side of things. When when is the release happening? What other changes from other teams need to happen in coordination with this? So just more from, like, the planning stage of it all, not necessarily who explain like, you know, echoing everything around what you said about, you know, we we're working towards our SOC compliance right now, and none of our devs, including myself, have admin access in our org.

We have a shared service account that handles all of our permission, our production changes. But that's not to say that there aren't changes that don't happen explicitly by me. It's just I'm typically the one that tries to coordinate things and lasso all of the, teams together and make sure that we're all in lockstep with each other.

Thank you. And I want to ask ask a question. Oh oh, sorry. Sorry, Jake. I don't know if we're out of time, but I just want to add a a quick question. So, like, just going back to the AI conversation, now that we have dev agents in in, you know, our at at very least in our dev sandboxes, how have you guys and I'm I'm just I wanna get you guys' input on this. Like, how have you guys changed your your controls from environment to environment?

You know? That that's something I'm I'm curious on it because you guys have a lot of experience with this. So just wanted to get your input on on this as well.

Arman, is that question to ask the panelist?

Or Yeah. Please.

I don't think we have. So I think we're at the very beginning of a journey of developing agent force agents as such, and we're much better as using tools with AI assistance for for developers or admins.

And, honestly, the the process has not changed for us because I still trust that the process we have is solid. It's more how people are looking at what they're doing. So when we have a peer review, when we have standards, you know, the standards needs to be updated. The the peer review needs to know that this is, you know, assisted generated as well code. So at the moment, we haven't changed anything besides looking at what the standards we wanted to follow and evolve that or address skills, for example, that we need to put together. Because, again, we are not looking at purely having AI generate the code without human in the loop, and I think that's what is very crucial.

Yeah. I I can echo that exactly. We already I I would say a fairly mature development dev DevOps life cycle process that we had implemented, you know, over the past course of the past couple years.

And because of that, it did equip us to allow our devs to quickly start using, at first, just we all were in the phase of just copying code from Cloud Chat or ChatGPT and copying and pasting it, copy paste. And now we're starting to get more into the agent space where our devs are using agents and just assigning the agent a Jira ticket and, you know, having the agent work in a sandbox environment. That is critical, though. Like, it's always been the the unspoken rule.

There's not even spoken rule of, like, your sandbox invite. We have a sandbox for every developer, which is nice. And so our our unspoken rule has been your sandbox is yours. If you break it, you know, I'll help you refresh it and fix it.

You know, you might, but, either way, your sandbox is yours to test and prototype and do as much as possible. And I think you were the one that mentioned before, Ram, that, like, from there, though, we have our quality control checks, and that's when you have to pass your static code analysis. You have to pass your peer review and things like that. That becomes more critical.

We don't have anything specific to flag right now if code is AI generated or not. It's something that we've talked about, but practicality speaking, the peer review is the same. The standard of peer review should be, if not, just as high, if not higher, with AI generated code kind of to prevent tech debt and stuff like that. You know?

So it shifts the conversation around what you're reviewing as a peer reviewer. But, like, like I said, there's there's no we're we're not fully developing end to end AI generated code into production. There's always, for us, going to be a human loop, and we wanna maintain that for the future. Like, we've had high level executive conversations, and I think most people, if not everyone, are on the same page that there will always be some sort of human in the loop.

But we are not going to implement a fully agentic workflow. Current state from the tools that we've seen, even on the most bleeding edge tools that automate everything, we still want some sort of human input always. So that's that's our just plan for right now.

Hundred percent. Yeah. Thank thank you for for sharing that. I I just wanted to see if it was any different than than the way we do things at at at the company. But, yeah, like like I was saying before, like, the the the controls haven't changed for me. The controls haven't changed since the pre AI days.

A dev could do whatever they want in the sandbox, but any higher environments and not just production. Right? Like, even shared testing environments where people are doing regression testing and things like that, we still haven't given AI agents AI dev agents access to those those environments to do whatever they want. Right? You you have a sandbox. You could do whatever you want or a scratch org. You can do whatever you want.

You know? At at that point, it's it's up to you. You could you you could the sandbox is yours. But anytime the the changes need to get promoted to higher environments, it still needs to go through that robust deployment pipeline.

I think that's that's yeah. Definitely. That hasn't changed even with AI assisted, you know, dev tools. And I think now it's even more important to have that in place.

Maybe before it was slightly overkill, but I feel I feel like now it's very important to have them.

Panelists, thank you so much for your time, your wisdom, and experience. I think one of the one of the core lessons, for me from listening to this session and to echo, what Stephanie said in this chat, this is a great topic and even more important now that AI has entered the chat. This should definitely be a panel session at Dreamforce. So maybe if anybody has any contacts in there, you could get yourselves on a panel at one of the theater stages and together again to talk about this.

This would be awesome. One of the key things I think that's important folks to take away from everything that you all have said is, know, governance, governance shouldn't be the excuse for moving forward. And I think we all have the solutions, and if we focus on the human in the loop and give ourselves the time and space to think about how we can implement AI solutions effectively, whether that be AI coding tools or AI agents, and we think about the roles and what we can do, then governance doesn't need to be a blocker. Governance can be an enabler for doing this thing safely.

So thank you all for your time. And for folks that wanna reach out to to Aram, Alex, or Aga, then I know that you're all on LinkedIn. So go and find them on LinkedIn.

So Thank you very much.

Time.

Thank you so much. Having us. Thank you. All the wonderful questions we had today.

Thank you.

Thank you, Jack. Yeah. Thank you all.

Alright, folks. So I hope you have all enjoyed what we've had from the summit to so far, the keynote and an amazing panel session. Thank you so much to Ago, Ram, and Alex. And it's only when I'm saying that I realize how many a's that is, and that's especially quite difficult to say. Speaking of a's, we have another a coming at you.

Andy Barrick is going to be here to talk to us about bringing visibility, stability, and control to your Salesforce org. So, Andy, I will throw this over to you.

Okay. Alright. I've managed to find the mute button. Excellent. We're away. Thank you very much, Jack.

Thanks for the intro and for the discussion and for everything so far. I hope you'll agree. It's been a a really enlightening session so far, and I hope to add to that. So let let's try it.

So I suspect then that most most of you on here, you'll have experienced at least one situation where you've started working on a new org or maybe, like, a different area of an org you're familiar with, and you've been somewhat racked with doubt, let's say, as to the consequences of the changes that you're you're about to make. Now, hopefully, fewer of you, but fear probably not. I've had, like, a change that you've made cause unforeseen problems down the line, actually often in production, and then had to try and replicate and understand that issue in, say, development environments to try and generate a fix, you can't get it to go wrong and so on.

So, obviously, none of this is is desirable or intended, but it is the reality, right, for a number of people working in it. So I've been in all those sorts of situations more than once probably as well. So I best introduce myself first. Andy Barrick, as you can see, I've been working in and around Salesforce for over a decade now.

I start out as a lead engineer at the at an ISV where there was lots of architectural discipline and rigor and things work really smoothly. There was a really fantastic development process in the days before scratch orgs and SFTX and all that.

Then I moved that into professional services for that ISV and then for other ISVs, and I found sort of the real world for the first time. You might say, what orgs really look like. So I've seen sort of both ends of the scale and a lot of stuff in between. I've spent a lot of time in projects trying to bring those ideas I learned to start with and practices from a suboptimal starting point. And that led me to gear set where I am today, where I'd really focus on doing that sort of stuff.

So why now? Like, complex orgs aren't new, are they? Obviously. But why why why talk about tackling them right now? And I think one of the main reasons is we've sort of alluded to and said explicitly in the last session is that AI is really raising the stakes here. Whilst we haven't necessarily seen anything like AI specifically before, I think we do have the history of disruptive revolutions to lead on and try and glean some lessons and ideas from.

So if we take it back a very long way to the something like the agricultural revolution, like, if the farmers used to scatter seed around, like, by hand to sow it all because that was the best way in which they could most efficient trade off between actually getting the coverage and the, you know, this built in wastage and whatnot.

So when when mechanization came along, what wasn't created was a machine that just shook seed around and then you'd wander around and say, oh, we we're gonna do the shaking for you. Things like a a seed drill mechanizes and really understood, like, what the the core aim was to plant the seeds, like, the specific that spacing apart and all that sort of stuff. So farmers can now sow sow far greater expensive land.

But if you think of it as an end to end process, if the if, say, like, the harvesting is still manual, that's not automated or you can't scale that up to the same level, then there's no real advantage in planting more areas because you can, but because the overall process was so limited by its narrowest bottleneck.

So that's exactly where sort of AI assisted development can leave a complex org. AI is is evident, the most prevalent, I think, these days. You you hear the most about it probably publicly in the build phase of the DevOps life cycle.

So if you can build changes faster than ever, but you don't know what those changes touch, you can't validate that they're safe and can't tell when something's gone wrong in production, let's say. All you've done is kinda move that bottleneck downstream. And we heard a bit of that in the last session, but but still the need for, like, manual code review. Right? Can that process scale by as much as now the build could theoretically scale because of AI? Right? You're planning pressure onto the parts of the process that may be least able to to take it, and the murkier the org, the worse that pressure actually gets.

So the the other the other impact to consider is cost. Right? Every stage further along the life cycle you go, an issue is roughly ten times more expensive to fix is the paradigm. Catch at the source, it's essentially free.

Catch your production, and you're disassembling. Right? It's not just the ten times. So if you've got even more on top, like, unpicking data dependencies and all that built on top of it in the meantime.

So if you're wondering whether it's worth the effort to fix, well, yes. Like, you wouldn't accept a factory working at forty percent efficiency. But that's what an org where every change is a gamble actually is. It's most of your capacity is gonna go on rework investigation and hesitation rather than delivery, and it'll cost you daily.

So that's why the goal of this talk is to give you, like, a framework for regaining, as the title says, the visibility, stability, troll that makes a whole life cycle able to keep up.

And, like, you might be thinking, well, our next project kicks off in August. There's no there's no time for all of this first. And that's fine because you don't need necessarily the whole framework in place to benefit. Even part of the step or a slice of the second or whatever is an improvement that you can carry on into that project and the one after that and then build on top. So let's have a look at it all.

So if we go back to that unfamiliar org we spoke about at the start, you're working on with little view as the consequences of a change. The that those remember those titles, visibility, stability, control, and noticeably absent back in that situation.

So a very common root cause of this situation is that there are, like there can be two different perspectives when it comes to org changes. So just kind of bring bring an analogy in. We got a picture like, punch in the air in celebration. Right?

That so most people recognize that as an expression of, like, emotion, but, you you can understand what's going on, celebration, etcetera. Someone who's, a biomechanist would look at that and potentially see, like, the the understanding of what's actually happening mechanically, like, a series of interconnected operations taking place in the body. Right? It's the same outward thing, but there's two entirely different interpretations, and both of them are completely valid.

If we bring that into the org then, the two perspectives are are sort of business process and the metadata components. Your end users, business analysts, etcetera are gonna think of the application as a collection of business process and what they actually do with the day to day with the org. Development and delivery functions are potentially more likely to think of it in terms of the components, the metadata items that that that actually constitute the the org itself. So when you're looking at this org, you don't quite understand.

You're you're trying to figure out both views potentially, the business requirements and the org metadata.

So step one of this framework is, like, understanding what the org actually does in business terms and building, like, a shared map between the processes the business talk about and the metadata components to implement.

Now the the processes are gonna be the most stable of the two. A business will typically, you know, issuing quotes, closing opportunities, etcetera, in five years time even if the components underneath have been rebuilt once, twice, three times over.

The developers here become, like, the biomechanist from the from the slide before, the person who's able to understand both the outward behavior and the mechanics underneath.

Now until until recently, there were there were three ways to understand and learn those core business processes and application support. You can actually go and speak to the business. You can speak to those products owners, the end users, and so on. What do their day to day roles actually entail? Which parts of the application, if they were broken, would bring them to a standstill, that previous phase, that really expensive end of the scale where production's down or blocked and you can't close opportunities and all that sort of stuff. Those are really critical business processes.

You could secondly, you could assess, for example, a historical ticket content. Now that's not particularly pleasant, but and there's always the risk actually of learning something from a ticket that's maybe been superseded. But, ultimately, an application's functionality should really be the sum of all the current acceptance criteria. If everything's been built correctly and met the acceptance criteria, then those will describe what the application does. And thirdly, you could potentially use something like the regression testing capabilities to understand what's being tested in quality assured before release. Because anything checked at that stage, that that it is you you would make a a a safe assumption that that's clearly something that the business cares about and enough to have protected it as a as a kind of red route through the release process.

But now, of course, as we mentioned at the start, got an extra tool in toolbox AI.

Org intelligence style products let you now have natural language conversations with your org, which lowers the barrier to that knowledge significantly. Like, you might be sat there thinking, my goodness. I'm particularly fancy looking at all the Jira tickets history. But now, you know, you clearly, you don't have to do that sort of thing. You don't have to find the right product owner or x great years of of of tickets.

Those solutions that are tailored to Salesforce layer in specialist knowledge understands not just what the metadata says, but but what it means, and help close that divide that we spoke about between the business processes and the components. There's an important caveat though, and that that's the AI typically uses the org or repositories it saw. So its answers are going to be grounded in what the application application actually does, not necessarily what it was intended to do.

Any bugs meaning that any bugs that are actually in the implementation get reported back as correct functionality because AI doesn't necessarily have that context for the original intent. Now, hopefully, that that gap is gonna be very small, but you can't count on it not existing. So in short, you can use AI to get fluent really fast, faster than ever before. Seed more more land just to go back to agriculture analogy at the start.

Get get get fluid really fast, then you can verify what you've learned with the people who know what that org is supposed to do.

And when you're armed with that knowledge, you can have that sort of equal standing conversation with the business, product managers, end users again, talking their language. Right? You've made that translation from the components into the into the business processes. You can have that with much greater confidence.

But, ultimately, having that universal language to describe what the org does and to you know, to talk about how it works, that's the foundation for everything that follows.

So that that's the visibility. I mean, that makes sense. You you you you get this understanding of what the org actually is designed to do. Ultimately, it's the visibility. Then we want to lock in the stability, which means that we prevent breaking or noncompliant changes from even entering the delivery pipeline and reacting to those that have With the best will in the world, you know, bugs will creep through, so we need to understand when that's happened.

The work we've just spoken out will obviously have given you that clear picture of what the application needs to do, this stage is much more about putting guardrails in place to ensure that that intent is reflected in reality, let's say.

So if we if we take the prevention side of it first, then for any item of work that is that is undertaken, whether that's rework arising from the business analysis you've just done or any sort of net new development such as that project within August we spoke about. There needs to be or there should be, like, a clear definition of done as as the phrase goes. Like, the quality gates have gotta be passed from that item to progress through each of the stage in the delivery pipeline.

And we spoke about QA testing a bit here. But, ultimately, QA is a wider activity. It's not just testing. But is this is has this met the relevant quality gates to pass to the next stage?

Like, the full definition of done should cover everything, like code review, security measures, test coverage, user sign off, everything that needs to be there. But any individual item will typically only need a subset. Right? If it's if it needs everything, it's probably a sign that it's probably too big a feature to be taken on.

But each gate should either be, therefore, like, achieved or marked and defined as not applicable before that item can progress.

And the gates for each item can and and definitely should differ per stage. If you if you're gonna retest the same acceptance criteria, for example, in every environment along the pipeline, ultimately, that's waste. And it means that, you know, you'll end up testing the org and not not necessarily the feature.

If you think we got on the left there the testing trophy, as you might be familiar with that sort of iteration of the testing triangle, I think Salesforce tends more towards a greater integration stage than than unit test.

You you know, you won't be doing the same QA at every point in an item's journey to production. It's entirely reasonable, for example, to say that if you refactor a piece of code that it only needs unit tested. And if the unit test passed, then you can be certain that the end to end process isn't affected because the the inputs and the outputs are all are all correct.

Equally, if you make a change to, like, a public API or global API, global Apex class, you might need to do that. You well, you will need to do the end to end test, but maybe the unit test is not actually gonna tell you very much.

So the the guardrails to build first then, those end to end ones. Once you understand the business processes, those routes through the application from entry point to the response at that stage, then you can put those automated tests around them. And you might you might well find bugs at this stage.

But use use Apex tests for the operation fits within a single transaction or automated UI driven frameworks for that process span several transactions, and you don't wanna be recreating database state in between in Apex because it's a pain and you break up on the limits and all that sort of stuff.

The latter evidently slower and their post deployment, etcetera, but they're they're really, the only option if if you want to automate those long running multistage processes.

So that that's prevention. But we spoke that there was two elements to to this stage.

The second half is reacting to to what gets through because we won't necessarily prevent everything going through even with those definitions done and those guardrails in place.

A core component to achieving the stability side of your org is, again, not just stopping them getting those new issues getting released, but having an oversight of how your changes are impacting things and acting accordingly. So a strong observability and monitoring capability in your org helps you do exactly that.

It's like the lighthouse here that we've got always watching, warning warning that you have the moment that something's gonna head for the rocks so that you can act before hopefully, before your users ever notice.

You know, this knowledge is also vital for prioritizing the fixes, finding your road map, etcetera, towards healthier org.

Now in the in an ideal world, you absolutely will be completely proactive on this. And as mentioned, you get to these things before your users notice you like the overnight batch jobs, etcetera. You can come in and have a look and understand if anything's broken, tie that back to deployments essentially and create tickets off the back of that. I don't think it's too big a leap to imagine a world where you are getting immediate feedback and tickets generated. And, hopefully, we're not too far away from those sorts of things.

Then finally, into control, the third stage. So what we've got at this point now, we've got an outline of the application. Right? We've got how it behaves, essentially, the entry points that we spoke about there. We have but we haven't got into the specifics or the components that the developers will will think in.

And it would it would have been it it would be wrong to start, like, going from the inside out. But now that you know that the behaviors that the application needs to exhibit, you can start drilling into how it achieves each of them. And that's where we move from that stability phase knowing which is essentially knowing the outline and making sure that things can't creep there into control, like managing the specifics of how each of those processes travel through the application's logic to meet the goals.

So this this may well seem overwhelming. It it could it could do. And and some changes are certainly out of scope. This we're not talking here about, like, massively reworking the database scheme given the sort of knock on effects that might mean for data migration and, like, having to repoint and rework external integrations and all that kind of thing.

But this is the layer where the business logic meets those components. And those two perspectives don't disappear, they move into the implementation phase where that translation belongs. So the communication with the business is always gonna stay in the language that they understand.

And this stage breaks the you know, the the work in this stage breaks into components, I think, where where each component has one and only one purpose, that single responsibility principle that you may well be familiar with with from kind of other objects oriented work.

You know, when it's named and described with semantically correct wording, then composing a process becomes becomes much easier. Right? It's it's easy to spot duplication, scope creep, and missing functionality to test properly with unit tests entirely separate from end to end processes.

I don't know how many how familiar this is to to any of you on the call, but I've certainly gone into in those ISV days, into a project with a customer with a huge org, and you look at well, I was in field service. So it was, like, a a trigger on the case object. And, like, the the the the after insert logic is all in one method called after insert. It's about four and a half thousand lines long, and you insert a case.

Like, what's what's gonna happen? You ****. It's just impossible. But e even simplifying that to a series of methods that that you can determine what route it takes based on the fields that populate on the object.

Actually, read it. It does that, then does that, then does that. It's it's so much so much easier to to debug and to understand what's been going on.

Now at this stage, if we go back to that biomechanist view of life, then we're into the the muscles and tendons of that of that person there.

But but thanks to the previous steps, the the application is now protected on two fronts. Right? We got the business shaped guardrails, business process shaped guardrails. So implementation issues can be reported back in the terms that the business understands.

You know, the the, like, you know, the you you might report back that. So the invoice generation process is broken. You can have that conversation rather than saying that a particular flow or class or whatever isn't working. And then you you've got, like, local policies such as naming conventions that can be agreed on in that u ubiquitous language that we spoke about before.

The Salesforce well architected principles that we've already heard about from Miriam in the keynote there enforced automatically through built in code quality gates. So you know that you're not making changes that that break those. The control isn't just factoring or refactoring well. It's it's standing gates that stop the org drifting straight back into the mark.

So I I do have to mention metrics quite quite briefly. It's is a topic of passion.

Changes like those that we spoke about there can be hugely valuable. But if you don't measure the impact or you don't capture a baseline beforehand to compare against, then the improvement is effectively invisible, which would be a huge disservice to the effort that that that go into into this one. If you already capture metrics around delivery speed and quality, absolutely keep doing that. If you don't, then the DORA metrics are a fantastic place to start because being able to demonstrate that not only the headaches, complaints, and confusion have reduced, but things like lead time and change failure rates have too is undoubtedly something to celebrate and proof that there's more visibility, stability, and control. And actually allows you to provide, like, almost like a a dollar value on the on a dollar value to the work that you're doing and to show that you are able to deliver that at an even greater pace once all the mark is away when you start a new item.

So a really important to bear point to bear in mind is that the return on investment of such an exercise isn't just a short term thing. I this will continue to provide benefit as long as those guardrails exist and are fit for purpose.

That return will continually, ideally, for years years to come, genuinely. A small piece of every feature to be developed accumulates quickly to become far greater than the original investment.

So in summary, to wrap up, we spoke about building a shared language between business processes and metadata so that you understand what the org really does before you touch it, creating guardrails around those processes to stop breaking changes getting in, plus monitoring the org to catch the ones that do, Adding well defined single purpose components held in place by standing quality gates so that the org can't drift back.

And that is the crux of regaining mastery over an unruly org. As you've gathered, like and probably, I think it is not gonna be a quick it's unlikely, let's say, to be a quick implementation. But well built specialized AI powered solutions that are now available really reduce the load significantly. Right?

There's never been a better time to undertake something like this, whether it's just understanding your org better for now or taking on the stability and control as well. And remember, regaining control is a process. Right? It's not a single activity.

That's it. Thank you very much for your time. Jack.

Andy, thank you so much. Always so calm, sage, excellent delivery, and a real powerhouse on every important DevOps topic. So, really appreciate your time and spending spending some of your day with us.

My pleasure. Thank you very much, Rob. Cheers.

You're welcome. You're welcome. Well, thank you very much, Andy. Another awesome session here as part of DirSet's virtual summit.

Thank you all for sticking around to this point. We, of course, have two marvelous sessions still to come. And the first of those sessions is with Annalisa Moreno, who is going to be talking to us about you don't have to start over, lessons from a legacy org. So Miriam was talking earlier about, or I guess, sorry, was talking about at the start of the panel.

You know, it doesn't matter how old your org is. You can still get it into shape. And having known Anna for the better part of a year now, she has some great things that we can learn from. So, Anna, if you are ready, then I welcome and invite you on to the stage.

Absolutely. Thanks, Jack, for that lovely introduction. I appreciate it.

You're very welcome. I'm gonna get out of your way.

Yes, please.

Alrighty.

Well, thank you everybody for being here. I'm gonna talk to you again about, legacy orgs. So picture this. You inherit an org.

Maybe it's fifteen years old. Maybe it's four. Doesn't matter. What matters is that somebody else made a thousand decisions before you got there, and now you're the one that has to live with them.

It's kind of scary. Right?

I've been there, and I'm here to tell you that it's actually a more solvable problem than it looks. But before I really jump into anything, I figure I should probably introduce myself. I'm Analisa Moreno, and I spent the last couple of years as the Salesforce release manager at GitLab, owning release operations for a global org of about fifteen hundred plus users.

But before that, I was inside three different orgs of all different agents all at once at Octane. Talk about legacy. But here's the funny part, though.

My actual entry into Salesforce was the complete opposite of all of this. My first project was actually building a brand new org from scratch. Blank slate, no baggage. So I've been on both sides of this fence. And I know exactly how good let's just start clean feels because I've done it. But I'm here to just tell you that it's not usually the option that you actually have.

So what does inheriting an org actually look like?

It's less like inheriting a house and more like inheriting a storage unit someone's been paying for since twenty nineteen and not opened in a while. Fields, nobody can explain.

Automation that clearly does something, but the person who built it left years ago and didn't leave a note behind, reports that are named CPQ sucks with a not safe for work description buried in the depths of old folders. The list goes on.

And it can be pretty disheartening. The instinct is often the same. Burn it all down. Start fresh.

New org. It's seductive because it's simple. And why not? Salesforce does it. They're on org sixty three or sixty four by now.

Except Salesforce also has Salesforce money. For the rest of us, let's just rebuild it isn't a technical decision. It's the perfect storm of budget requests, resource conversations, and a timeline nobody actually has.

And if even if you could greenlight it, starting over isn't necessarily a fresh start. It's just a different kind of debt. You're trading the, I don't understand this org for I now have to migrate fifteen years of business logic, loads of data, and institutional memory while also keeping the lights on.

That's not starting over. That's starting a much bigger, much riskier project badly.

So if you're sitting there thinking your org is too far gone, too tangled, too old to fix, actually, you wanna spend the next fifteen minutes convincing you that you don't actually have to start over. You just have to start somewhere specific. And figuring out where that is, that's actually the whole job.

So where do you actually start? Honestly, before we can answer that, it helps to get clear on what legacy actually means because I don't think it means what we typically act like it means.

So let's redefine legacy for a second because I think the word does us a bit of a disservice. We tend to use it like it means old, but age isn't really the problem. The problem is inheritance.

A legacy org, in my opinion, is any org where somebody else made the decisions, they didn't document them, and you're now the one holding on to the consequences. By that definition, a four year old org can be just as legacy as a fifteen year old one.

If you're new, if you didn't build it, if nobody documented why things are the way they are, congrats. You've inherited a legacy org.

The storage unit's been filled with boxes big and small with illegible handwriting for you to interpret.

And I kind of got to see this play out almost like a controlled experiment while I was at Oktane. I worked across three orgs all at once, Oktane itself, Stamps dot com, and Packlink, all different ages, all different histories, all inherited at different points by different people.

And what struck me wasn't how diff different the technical problems were. It was how similar our organizational problems were. Each one had its own version of nobody knows who set this up and why it's set up this way. And we've been meaning to fix this for years, but we just haven't gotten around to it.

And that's when it clicked for me. Moving an inherited org forward is not only a technical project but an organizational one, too. The complexity you're staring at didn't appear from nowhere.

It accumulated because of organizational demands, sales processes, service requirements, or integrations, you know, someone needed at the time, which meant means untangling it isn't just a question of how you move from point a to point b, technically.

It's a question of whether point A still needs to exist at all.

If you only focus on the technical stuff, the migrations, the cleanups, the automation fixes, you're only addressing the symptoms, not the cause.

That reframe is what matters because balancing your organizational problems with the technical ones can be really tricky.

Lean too heavily one way and the other side could suffer.

So let's work how you actually tackle this.

So when you're standing in front of your own storage unit trying to figure out where to start, you need a toolkit to help sort the organizational problems.

You could make a case for fixing almost anything in an inherited org. So when answering the where do I start question, what you really need to understand is sequencing. What actually needs to happen now versus what's allowed to wait?

And not everything you inherit is on fire. Some of it's just old. Some of it's ugly, maybe inefficient, maybe, but it's stable. It's working. And one of the harder skills in this job is leaving that stuff alone on purpose, not because you don't see it, but because your time is better spent elsewhere.

So I think a rough now versus later split is this. Now is anything actively causing pain or anything sitting right next to something you're actually going to be touching. So fixing it's basically free while you're in there already.

Later is everything else. The weird but stable, not going anywhere sort of stuff.

Except later doesn't always stay later. A perfect example was actually a GitLab. For us, connected app and OAuth security review was firmly in our later pile until GitLab ended up on a public list of orgs that had been compromised by a connected app specific breach.

And that forced us to take a hard look at our later pile.

Overnight became now for everyone, including our corporate security team, not just the Salesforce team.

But here's the part that actually matters, though. Now doesn't have to mean all at once.

You cannot audit hundreds of connected apps across a decade plus org in a single sprint, and pretending you can is how these projects collapse under their own weight almost immediately.

So the real work is breaking down the deal with this now into something attackable. Sort before you act by risk, by usage, by whether anyone can even explain why something's connected in the first place. That sort sorting turns one undifferentiated pile of dread into a sequence you can actually work with.

This is somewhere I think AI can generally help. Getting visibility across a sprawling org used to mean weeks of manual editing.

Now AI can compress that groundwork, surfacing what's connected, what's active, what's been sitting untouched faster than any human audit could ever.

And that's useful when you're staring down that now versus later pile across your decade plus org.

But here's the thing that it can't do.

It cannot tell you whether the marketing team still needs that integration. It can't tell you whether now is the right moment to move politically organizationally.

It can surface the picture, but it cannot read the room. That part is yours to handle. And, honestly, the value of good human judgment doesn't go down when AI gets better at the groundwork. It goes up.

Okay. So now you know the order of attack. What's next?

Now you need to figure out who this is actually for. Leadership, maintainers, or users. Each of those groups thinks in a different currency.

Leadership thinks in risk and cost most often.

Could this bite us in the ass from a sales perspective later? Will this save us money or prevent a worse expense later?

Maintainers, like many of us and myself, think in time and sanity.

Will this actually stop me from dodging the same five landmines week after week? What's the short term pain versus long term gain of this actual change?

And then users, they think in experience.

Does my day to day life get better or worse from this? And how much harder or easier will it be to do this one task?

The same fix can be a strong pitch to one of these groups and a complete nonstarter to another.

And it's not necessarily because the fix is wrong. It's because you're speaking the wrong language.

This is technically cleaner, could often mean nothing to leadership, even the most tech read.

While this reduces our audit exposure, definitely means nothing to a rep who's just trying to log a call.

So before you build a case for anything, the real first step isn't how do I convince people that this matters? It's in whose terms does this already matter? And am I talking to that person yet?

The fix doesn't change, but the framing does. And figuring out framing is the most of the work. The technical part is usually the easy part once you actually know what you're solving for.

Alright.

Now you can go ahead and make the change. Right? Well, not quite.

Once you know what needs to change, the temptation is to treat buy in as a formality. Get sign off, send the notice, move on.

That version is technically compliant. It's nice in business terms, but it can still blow up in your face. Because somewhere, someone's relying on that one thing you just changed, and they find out after the fact. And they can get very angry very fast. Trust me. I'm speaking from experience.

Real buy in is the opposite of a formality. It's going to the people who will actually be affected before anything changes and asking what this does for them and what they'd actually need in order to be fine with us changing it.

Sometimes the answer you'll get is nothing. We totally forgot we even had that.

Sometimes it's we use this for x process. Can we sort that out first?

Either answer answer is useful, but you only get that if you ask before, not after.

This is also where champions matter, not just people who approve something, the people who actually want it to happen and whose support carries weight with whoever else needs convincing.

A champion in the room with you is worth more than a dozen people nodding and smiling in a meeting they're gonna forget by Friday.

So buy in isn't a stamp you collect. It's the process of uncovering how your change impacts someone else's work while you've still got time to do something about it.

If you get that right, the actual rollout is usually the boring part.

Now as a team, once you've worked through this entire process, don't let your hard work evaporate.

The conversations you had with stakeholders, the reasoning behind what went in the now pile versus the later pile, the champions you found and what mattered to them, write it down.

Doesn't have to be a formal governance exercise, but as you go, things like linking your issues or your tickets to component descriptions for reference, noting your build logic in a comment when you've actually touched something.

Keep a scoping template handy so the next time this happens, you're not starting from scratch. The list, again, is long.

Small habits consistently applied add up to an org that's actually navigable and sustainable.

But here's the thing. None of that sticks if it's just you doing it. Buy in doesn't stop at stakeholders and champions. It has to extend to your own team too.

That means making it easier easy to do the right thing. So like I said, templates, clear conventions, and a shared understanding of why this matters.

So that labeling your boxes and your storage unit aren't a personal virtue.

It's just how your team naturally operates.

Because the person who inherits this org, and there will always, always, always be a next person, deserves better than a storage unit full of boxes with, again, illegible handwriting. You already know how that feels, to be the team that labels the boxes.

So I'm going to derail this for a second, and I want to tell you about a guy my former manager at Octane met at Dreamforce.

He was a sole admin for a huge trucking or manufacturing company who'd been there for years, and I have a feeling he's going to fact check me about this later.

His whole strategy was simple. Don't make massive changes unless you have to. Upgrade what needs upgrading, keep the lights on, and leave the rest alone. That's it. That was his job. Talk about job security.

Someone hearing that for the first time might think that's not a strategy. That's just the bare minimum, keeping things moving and keeping the lights on. He's not actually doing the hard work of long term health. He's just coasting.

But I don't think that's the right interpretation.

I think doing KTLO well for years, making good now versus later calls every single week, that was his long term health strategy.

He just never had to give it a name because it never piled up into something that needed its own initiative, its own steering committee, its own we need to talk about this overhaul meeting.

That's really the answer to the tension everyone feels between keeping things shipping and keeping the org healthy.

It's not actually two things competing for your time.

The orgs that end up needing a scary, separate, rebuild this conversation aren't the ones that necessarily did KTLO. They're the ones that where the now versus later calls got made badly or not at all for long enough that later quietly turned into everything all at once. Oh, and also it's on fire.

So if you're standing in your own storage unit right now, looking at fifteen years or four years of someone else's decisions, here's the actual takeaway. You don't have to empty your unit.

You definitely don't have to torch it and rent a new one.

You just take a deep breath and pick one box.

You open it up, and you figure out what's in that box and who it's actually for.

You decide, honestly, if it's a now box or a later box.

You use your DevOps tools, use AI to find out how your business logic links up. And if you can, find whoever has been around long enough to tell you why it's labeled that way.

That's it. You don't have to start over.

You just have to start somewhere specific with one box for someone specific and trust that doing that over and over is the long game.

Thanks.

Anna, thank you so much.

Yeah. Definitely.

That the the storage storage unit analogy landed pretty pretty hard. There you go. A couple of great reactions.

That's that was awesome.

I'm glad.

Thank you so much for your thank you so much for your time, and I hope that everybody has taken that for for what it should be. Like, we should be we should be encouraged. You know? All is not lost because we have inherited one year old storage units or fifteen year old storage units. You know? There is there is a path out of this for for everybody, and, you delivered it so nicely too.

So thank you so much for Thank you.

Thank you.

For your time.

Yes. Absolutely. Cool.

Thank you so much. Folks, thank you for sticking around to the final session of this summit. My good friend and colleague, Ali, is going to be coming on to show us a little bit about how we can take control of our orgs and what control looks like with Gearset. Obviously, we are all looking for solutions to our problems, and Gearset has a few things up our sleeve, that may well be able to help you on this quest. So, Ali, I would like to introduce you to the stage if you are ready.

Yes. I am. Thank you so much, Jack. Awesome. And with that, we can go ahead and dive right in then, spending the next ten or fifteen minutes taking a look at what that control looks like inside of Gearset.

But very briefly on my side. First, my name is Alastair McGrath. I've been with Gearset about four, four and a half years now working as a senior sales engineer. Over that time, I've worked with hundreds of teams looking at many different DevOps processes.

And, yeah, I'm here to show you what's exactly Gearsit can do in these cases.

So we'll dive right into the tool then. Really just going at a start to finish throughout that software development life cycle then.

A little bit of context on Gearset itself. It is entirely off platform. The implementation is relatively lightweight too since there's very little to install on any of your orgs. Just using OAuth connections, we can connect it to your stack. So Salesforce orgs, service control repos, third party services, all being managed from a single place.

On the left hand side here, we have those different modules. And immediately, before I start building work, I wanna make sure I'm clued in on the changes that I need to make.

Let's say I've inherited a fifteen year old org. This org intelligence tool is then how I can untangle that, giving me a top down view into breaking down those complexities and untangling that mess.

Now there are two navigation paths I can take here, either deterministically searching through all of my different metadata components or working agentically to ask context specific questions about my environment.

So if I reach out to the agent, for example, I could ask about a business process, what happens when an account industry changes. That'll help me navigate to any automations in question. That way, I can get unstuck while tackling any existing tech debt within that environment.

Now this is super useful for onboarding new folks who might otherwise need time with senior teammates. But if I am working within an environment that has a lot of structure already, it helps me see beyond the metadata structure itself, having things like descriptions generated automatically. I can save this internally or externally to make sure the next person who comes to this has a good explanation of what it actually does.

But beyond the structure, it's also giving me insight into any emergent business functions.

So how does it work, and what does it do?

Off the back of that, I can understand, are there overlapping functions? Maybe there are some Apex classes that can be deprecated.

Can I make things more efficient?

And if I'm starting to scope a change, I can get that awareness then of dependencies, permissions, even.

Once I'm included into those existing issues then, I'll, of course, start building within my environment, and I can use Gearset to carry that change forward either directly from one environment to the next. Or in my case, if I have a fully source driven process, I can manage that through Gearset's pipelines.

This is that one process then to govern all changes that are being shipped wherever they're being shipped and whoever's shipping them. So for example, admins working out of a shared environment, developers with individual developer sandboxes, or even agents pushing things are all gonna be managed through the single interoperable pipeline. And GearsUp managing the CICD portion is gonna make sure that all my environments are in sync. So I've back deployed latest changes to my dev sandbox before I started working. And then when I carry it forward, it goes through any of the different quality checks that I need. That way, I can maintain stability and control after I go ahead and create my pull request.

Those different quality gates then are gonna manage whether or not things can or should be deployed, tracking things like manual or automatic pre and post deployment steps, running dynamic levels of testing.

And they'll have all of that within one singular view once that pull request is open. Now regardless of where it's come from, I'll see them whether it can be merged. So if there are any conflicts against what's already in that environment, if there's any validation issues that might need to be resolved, and then whether it should be merged. So taking a look at the code review side of things and making sure I'm not introducing many different errors into my target environment.

Taking a closer look at that code review then, yours has its own static code analysis tool, and they can show me any of the issues that might crop up before they're merged into any of my testing environments or production.

And this is based on the Salesforce well architected framework as well as the OASP top ten guidelines.

And this is meant to supplement my peer review with deterministic quality gates rather than letting AI review AI.

On top of that, it's only flagging net new issues, so it's not overly noisy.

And those custom levels of gating can be set depending on where my team is with the level of quality checks that they need to enforce.

So based on the context and the severity, in my case, it's caught that I have some, incorrect sharing clauses within the ape an Apex class.

But it's not just limited to Apex. This is also looking at things like Lightning Web Components, issues with flows, allowing me to incrementally improve every single commit that I push forward.

On top of that, in some cases, it even has automatic resolutions available.

The actual process for getting around any of these quality gates can vary.

Your set does support rollback. We very thoroughly support fixing forward. And in the case of those static code issues, this means that in flight piece of work is gonna be updated with the code reviews resolution.

After that, as usual, the pipeline will manage my environment sync.

The next layer of whether or not things should be deployed is gonna come in the form of testing.

Now previously, maybe everyone on the team is manually doing regression tests on a per feature basis.

But in order to really spread the load of that work, GearsNet also has a UI testing tool. That way, can perform regressions on that work as it moves through my pipeline triggered automatically on each PR that's merged.

This allows me to simulate different profiles, different users, different permission sets.

That way, I don't have to manually do it every time. I could just build it once and then reuse it in different environments and different contexts.

Effectively, spreading the workload of that QA process then and relieving the testing bottleneck, I can then take these changes and shift them forward towards production.

Here still, the avenue for release varies. I could release an isolation. I could bundle these into larger projects or release branches. But overall, I'll have that confidence that when it does reach production, it hopefully isn't gonna cause any more issues.

Now as for the state of things in production, those same scans, the step code analysis with the code reviews tool and the UI regression tests can also be run-in that production environment. That way, I can identify any existing tech debt across my entire org or repo. For example, are there security issues, are there excessive user permissions?

And that brings us to the final point of the development life cycle in Gearset with our observability suite.

Now any errors that do crop up, I can immediately be notified because this can keep track of any API limits that I might be reaching. That way, I don't run into some catastrophic, failure from API limits being surpassed.

As for those levels of access, I can use this to help triage any overprovisioned users or check on license allocation within my environment.

With the errors themselves coming up with flows and Apex, I'll see that mapped out against the deployments that I've been making in Gearsup. That way, if I see a huge spike, I know this might be something that I need to roll back.

But for triaging, I can drill down, see who's actually running into these errors, and have all the information that I need to actually start remediating that.

At the very end of the process, then I can add this to a ticket or create an entirely new one. And though I might assign this across the team, I do have another final option in year set to leverage AI to spread that workload around since I could now hand that ticket off to an agent to actually build and start working on a resolution.

I'll tell it to start working out of one of my developer sandboxes then. That way I'm not getting unexpected changes too far upstream.

And once it's assigned, it'll start working with me, to build that resolution, which once completed, I have a chance to review before shipping it through the same exact covered, governed pipeline as before. So working from that Kanban board, I can see what it's produced, in my case, a flow.

And now I can promote it back into the pipeline, again, starting over that software development life cycle process.

Now in the chat shortly, we should be dropping some scheduling links. Jack's gonna share some ways that we can get in touch with you after the fact if you'd like to see any more about any of the things I've flown through today. Overall, I have really only shown about half of what Gearset has to offer. But thank you so much for your time. I appreciate you staying on. Jack?

Ali, thanks so much. Thank you so, so much. I hope if you have been with us from the start of the summit or even for just a small part of it and have seen what Ali has shown you today from Gearset, there is solutions to your problems. And here at Gearset, we wanna help be the answer to how do we solve this, how do we fix this.

So if you're looking to find out more about what we can offer, if you'd like a deeper dive into any parts of Gearset's platform that Ali has shown us, then please do reach out to us, and you can do that, by heading to gearset dot com. You have the option to, connect with us over intercom, the little chat widget down in the bottom right hand corner, and there will be, various links and ways of contacting us if you would like to book a demo or other ways that you would like to reach out to the team. Failing that team at gear set dot com will have all the information. And, of course, post webinar, we will be following up with links to all of the recordings from every session that has taken place today.

Feel free to respond to those emails if you would like any more information, or to connect on any of the topics that we've been talking about today. You can, of course, do that. That leaves it up to me then to thank every single one of our speakers that we've had today. The panelists, Miriam, Andy, Ali, and Alyssa, thank you so much for sharing your wisdom with us.

These virtual summits, I always have a really phenomenal time, hosting them and listening to the expertise from so many wonderful folks across the Salesforce ecosystem.

And I would encourage you, again, visit Gearset dot com. And for the Well Architected Framework, that's architect dot salesforce dot com, for all the information that you might need, to handle your orgs now and into the future. For other events, please be sure to, connect with your local trailblazer community groups. I'm a huge advocate for engaging and participating in the wider trailblazer community that we have. So please check out, the trailblazer community and see where the local meetups are in your area, and continue to work together, to make the Salesforce ecosystem, our Salesforce orgs, and our organizations the best that they can possibly be. Thank you for your time, for your commitment, and I hope to see you all on another Gearset Summit or out and about at Salesforce or Salesforce Community Conference sometime soon. Thank you very much.

Compare & deploy

CI/CD pipelines

Backup & restore

Taking Control of Complex Orgs Summit

Compare & deploy

CI/CD pipelines

Backup & restore

DevOps done right

Ebooks & whitepapers

Webinars

Blog

Podcast

DevOps report 2026 New!

DevOps training

Help center

DevOps assessment

Why choose Gearset

Customer stories

Integrations

Security & trust

Events

DevOps Leaders

Feedback forum

New from the blog

Salesforce test automation: A complete overview

New from the blog

Support on your terms: how we think about AI in technical support

New from the blog

How Salesforce UAT fails and what to do about it

Taking Control of Complex Orgs Summit

Description

Transcript

Contact us

Customer support