Salesforce DevOps: AI and the lifecycle advantage

Share with


Description

AI is everywhere — but value isn’t. In this on-demand webinar, the Gearset team introduces Org Intelligence and Gearset AI — and shows why these innovations matter not because of the hype, but because of the strong fundamentals they’re built on.

See how taking a full DevOps Lifecycle approach with early validation, automated testing, code reviews, observability, and rollback, provides the foundation AI needs to be truly effective. It’s not just about new tech. It’s about putting the right tools, in the right hands, at the right time to deliver faster, safer Salesforce releases.

Jack McCurdy, DevOps Advocate at Gearset, and Analissa Moreno, Salesforce Release Engineer at GitLab discuss:

  • The impact of AI and what it means for the future of Salesforce DevOps
  • How a lifecycle approach is more important than ever in the Agentic future
  • How teams are using Gearset to shift left, look right, and deliver continuous value at scale
  • New capabilities launched: Org Intelligence and Gearset AI

Further resources:

Transcript

Thank you so much everybody that has taken the time out of their day today to attend Salesforce DevOps AI and the Lifecycle Advantage. It's an absolute pleasure to host you today and hopefully educate you on some pretty cool developments in the Gearset product and also have a great discussion here with Analisa about AI and Salesforce development and the state of where Salesforce DevOps is at.

Today's speakers. So I'm your host, Jack McCurdy, DevOps advocate here at Gearset. And as you can see, I'm joined by Analisa Moreno, Salesforce Release Engineer at GitLab. Hi, Ana.

Hi, I'm doing well. It's actually Analisa.

Analisa? It's all good. See, I'm good. You know, how many times have we spoken and still can't get it right?

It's because I never introduced my full name, that's why.

And we have James Potter as well, Development Team Lead also at Gearset, that is gonna be walking us through Org Intelligence, the newest part of the Gearset application.

But to set the scene a little bit and tell you all why we are here, we at Gearset are more and more confident that Salesforce teams that are looking at the whole DevOps life cycle are the teams that are going to be the most successful when adopting new initiatives like Agentforce, as well as the continual ongoing management of their Salesforce orgs. So folks are able to plan, build, validate, release, operate and observe their orgs in a great manner. Those teams that are security minded, have great testing, collaboration and automation are gonna be the ones that succeed.

We also are acutely aware of the impact that AI is having on our day to day lives. So I'm sure many of us here are using various forms of AGI in their day to day work, whether that be tools like ChatGPT or Agentforce itself or Claude or Copilot, whatever it might be, AI is taking up a large portion of our time. So it's really important that we address these issues and this change, this fundamental shift in the ecosystem that we are seeing. And that has led a lot of folks asking me specifically and the team here at Gearset, where does AI fit into the DevOps life cycle? Where can I use AI in my DevOps processes?

And that's predominantly what we're here to talk about today and the subject of our Q3 product launch, Org Intelligence. The plan stage of the DevOps life cycle, the stage in which you ascertain what it is that needs to change, how you take user stories, requests from the business, and turn that into a product, an application, or an update in the Salesforce ecosystem, Salesforce platform, that you can make sure that you fulfill those needs and requirements. And this is a really interesting space where AI can be used to a lot of great strengths and opportunities, really bridging that divide and allowing us to make sure that we are focused on the other parts of the DevOps lifecycle that we can improve and change.

So what we're going to do is we're going to show you Gearset's org intelligence. I was super stoked when I saw this product come out and the demos that I've seen and the reception that we've had from our customers, our user base has been absolutely phenomenal. And to do that, I'm going to need to introduce James Potter, Development Team Lead here at Gearset. So James, welcome to the webinar.

I'm going to leave the listeners in your capable hands.

Ana, I hope you had some fun watching this as well.

Yes, Jack. Yeah. So I'm James. I'm an engineering team leader at Gearset and, yeah, help build a bunch of the stuff I'm about to show you. Let me just share the screen.

Cool.

Perfect. So as Jack said, we're focusing on the build phase for this. And yeah, I'll the demo to do most of the talking as it'll explain a lot of what it's for and why it's useful for the build phase.

All start, a lot of us start at the build phase.

If you're not sure what you need to do in order to make the change, then it's nice to have a place that you can go to sort of validate any concerns you have or any dependencies and issues that you just weren't aware of before. So starting from, let's say, a Jira ticket, we've got this discounting process here that someone's asked for.

Account industry changes, I'm not really sure what that means, so let's go to this Org Intelligence panel.

So this is now inside Gearset in this Org Intelligence solution, and now we've got two big things here. We've got all of our org data on the left here. So this is all loaded from this production org. I don't know what the name of it is. This is the friendly name. And then we have this agent on the right.

I'm not really sure where to start with this. I don't really know much about account industry changes. So let's just ask when an accounts industry changes, what happens? Oh, happens.

Cool. And so what the Gearset Agent is going to do now is we've got lot of the pretty much all of the org semantically stored in a fancy data store somewhere.

The agent can make use of that, figure out what sort of items it needs to look at, like figures out all of the things that relate to account industry changes in the org. So for example, you can see it search for a bunch of stuff in here for a bunch of references, account industry field references, and then it's now doing some sort of analysis on that metadata and how it sort of spans within the org and different items.

We'll just leave that going for just a second. But yeah, just helps you to get deeper insights than just looking around in your org when you're not sure exactly maybe what a certain process, maybe someone else built it, maybe it's like an older part of the org that you're not so used to.

And yeah, so here we've got the answer. So when the industry field changes, the main automation run is this flow. That's interesting. Okay, cool.

I don't know about this flow. No Apex triggers, no process builders. Great. So let's have a look at this flow here by clicking on it, and now we've got the the lovely flow nav and we can sort of see what's going on.

Okay. So a little bit bigger of flow than I hoped for maybe. We've got some Get Ops, we've got some Needs Analysis, and if we wanted a real quick explanation of this, we've got this little explainer explain item down here. Maybe someone who's more new to Salesforce or isn't used to this particular flow.

I mean, a lot of customers that I've talked to have flows that they don't really want to touch or owned by certain people. And it's really nice to show you can navigate the flow in the flow navigator, but sometimes it's nice to just read through something and think about how that fits in together with the larger org. For example, the retrieve Open Opps creates all the records relating to update account where stage name is not Closed Won or Closed Lost, for example.

Cool.

And so that's nice and all. We now understand a bit more about this. We can dig into this flow, but what I actually want to do what this ticket says? So we've got description, sales manager, want to update this process. Currently, it does this. The updated version needs to do a bunch of things. We want robust fault handling, we want to incorporate some existing Apex actions, so let's just paste this directly in.

Cool. So luckily, it doesn't really need to look up anything at this time because it's already done a query before on this whole process and sort of understands the whole all of the metadata before it. So it just goes straight into explaining it you'd clone the existing flow, update the trigger, insert these two Apex actions, and we can have a quick look in here. Opportunity discount calculator, cool, or the payment method.

Then it's update a step stage name to proposal slash price quote. So a decision element, so we go to this flow and you can see that we'd add a decision element to evaluate that. Not sure where to add that, but the opportunity stage Won is particularly interesting. So add a step to update related opportunities stage name. So I think looking at it, it'd be somewhere in this update opp assignment and the stage name here looks like this instead of assign would be proposal slash price quote. And something else interesting is not really sure what this means here, this proposal price quote thing, so why don't I have a look for that? So going back to the whole org, we've got this search inside metadata thing and actually searching for this string, on all the metadata in the org actually, oh, opportunity stage, I see this value set contains this.

It could be a nice way of seeing exactly where some of these values exist when you're needing to make changes to them. That's why it used to be needs analysis as it was talking about earlier. I'd actually want it to be on proposal and price quote.

And yeah, that sort of gets pretty to the end of that. And yeah, we've got like a nice thing to follow in order to make this update and really showing the value of like the plan stage and things to consider that you might not have done before.

I'm thinking about the default handling and using email alerts and notify admins.

And yeah, thank you. Thank you for listening.

Wow.

James, thank you so much. Ana, what have we just seen? As I understand it, this is your first time seeing it. So what do you think?

Where was this a couple years ago when I was working at Octane? This is amazing.

Honestly, I we've I've used a tool like this before, but this is so much more robust. And honestly, being able to just search the metadata for something as simple as pick list value is amazing. So I can see this being so valuable in my current role as well.

We struggle with this every day, and I know that this is one of those things that many orgs struggle with, teams big and small. So no, this is so cool.

Thank you. James, we do have a question in the chat here as well from Conlon. Did Gearset Agent just create the components or write the suggestions?

No, it doesn't currently do any building of any kind. It's pretty focused on the plan phase.

So yeah, it's good at exploring the metadata, understanding the relationships, talking about how you should think about making the changes, but it's not quite at the point of making changes.

Cool. Thank you. James, I imagine that we're going to get a lot of questions in the chat here from the folks that have seen the Org Intelligence demo that you've just shared. I can already some rolling in.

The good thing is for the folks in the chat, James is going to stick around and answer some of those. I would encourage you to use the Q and A functionality in Zoom so James can respond directly to each questions. But James, thank you so much and wow, what a game changer. Ana's already expressed as much, so thank you so And folks, like I say, if you have questions for James, please hop into that Q and A.

Ana, already impressed from what you've seen. What's your take on AI and Salesforce development and what are you seeing out there at the moment in terms of maybe what your team's doing or your peers are doing, especially sitting in a release engineer role?

Yeah, definitely. AI, I feel like is really used in so many different ways.

We, as a team, generally speaking, don't use it a ton. I think on an individual basis, developers and admins use it more to augment their own work, which I feel is kind of how AI should be used. It's really should be used to augment your own world.

So that's really more of an individual basis. As a team, we're not using it, you know, to do a whole lot of stuff, which is okay because we're still kind of in the, you know, early phases of our pipeline and trying to stay stable before we start introducing more things into our steady state. But I can definitely see us introducing things maybe in 2026.

Yeah. You mentioned a really interesting word there that I think a lot of folks in Salesforce and Salesforce engineering and DevOps specifically, we talk about stability quite a lot. How important are those stable foundations when you're making big changes to any processes or practices that your team is following?

Honestly, I think stability is a key factor in a lot of area, and I'd say in every process.

I think one of the biggest challenges is that you a lot of teams get that outside pressure.

There's this urgency and expediency that kinda gets applied to them. And it's like, we need to get something down now now. I, as a release engineer, definitely feel that.

And I understand the reasons behind that. You know, there's usually like a business case riding on it. There could be millions of dollars, a deal, etcetera.

But if stability if if you're sacrificing stability for that urgency, things could be impacted down the line. So it's kind of weighing the risks, versus the reward. I think that's that's really key. And making sure that you can at least try and keep some stability in there, so that your path forward isn't going to be just trying to be janitor essentially and clean up the mess that might have been made just so that you can get things out the door.

Yeah, that says something about the somewhat move fast and break things Yes, definitely.

That move fast, break things culture is all well and good until you're constantly putting out fires.

One of the ideas and one of the things that I quite like, now there's sometimes concerns is what if we implement things like Agentforce or bring in agents to augment our work? What happens to us being replaced. When we look at something like Org Intelligence and how that changes our efficiency and improves our efficiency for our changes, then we don't have to firefight. We can still move fast, but not break things because we have more time to consider all the changes that we're making and the proposed processes or changes to business processes, the business cases that you mentioned there as well.

Do you think there's a space where or do you think AI is going to fundamentally change how we do things?

And are people really going to be able to focus on the more value stuff? And are you seeing any of that at all in anything that you do in your work that is aided by AI?

You know, is it going to fundamentally change things? I think in some capacity, yes. I think it's already done that. Again, like I said, it augments so many people.

I think it's kind of a slippery slope too because I feel like it's a pendulum. The pendulum is currently swinging so far to one direction because there is that fear of being replaced instead of working with it to help us.

But I think that's kind of the challenge that everybody is facing right now and especially businesses are trying to make that decision, where do we insert this so that we can make those changes.

In kind of like my own world, again, it's one of those things that, it's tricky.

We just are moving so fast that we haven't been able to kind of sit down and gather our thoughts about it, specifically in our Salesforce. But I can definitely see where it would be able to augment us.

Specifically, Org Intelligence would make our lives much easier because we are a thirty person team, and that's just the Salesforce team. We have our, you know, our lead to cash team that is working in the CPQ. That's, that's a different tool. And that that overlaps with us in so many ways that if we could know all of those connections ahead of time, we would be able to preemptively fight those problems, then have to be reactive. So instead of having to be on the back foot, which sometimes we find ourselves on.

Yeah, yeah. Again, that speaks so much to the human skills and the collaboration aspects of our role.

Another question I get asked is, so what do I do now? What do I focus on? And these intertwined systems, these connected systems that are the backbone for our businesses, we need to support in the best way we can.

Yes, AI, please help me with the bits of my job that can be automated so I can continue to build on the collaboration and build effective systems. So, to your point of being able to liaise with your CPQ teams more efficiently and actually quite actively do things, then that's great. Is there any other foundations that you think would be essential for folks adopting agents, either in Salesforce and doing Agentforce, or when looking at their DevOps lifecycle or DevOps approach as a whole?

Well, think three things kind of come to mind with that. I think it's just generally when you're trying to adopt those new technologies, it's compatibility and alignment with your process. Like, what does your process look like right now? You know, can you translate that into, like, what you're wanting to do, or are you gonna have to, like, rebuild from the ground up? You know, I think for newer teams that are getting into DevOps, the world is your oyster, which I think is so cool.

But for more established teams like my own, finding a tool or, you know, tools, etcetera, agents, etcetera, that align with where, what you have and where you wanna go can be a challenge. And that's one of the biggest hurdles you gotta jump. The other thing too, think is intuitiveness. You know, how easy is it gonna be for your team to be able to to be able to pick up, to be able to build, to be able to implement, how is it gonna affect, you know, your user base? I think a good tool should strengthen your processes, not complicate them. I have been a part of many tools that have complicated everything.

And then you're an admin, what am I doing? Oh my God.

And then it's just kind of snowballs from there. And then I think at like the last thing that's really important is scalability. How is this going to grow with my team without adding friction? Obviously growing pains are kind of normal, but if that tool or tools, etcetera, that you decide to implement becomes your bottleneck, that's a huge red flag. So it's trying to kind of piece all these things together to make sure that you kind of have a solid plan going forward.

Yeah, absolutely. You gotta fail to prepare, prepare to fail.

Yeah, yeah.

And it's okay. I think it's okay if you fail to, you know, it's iterative. That's literally part of DevOps is iterating.

And I think if you can be comfortable with that, then you're already on the right foot going forward.

Yeah. You are speaking my language. That's one of those things that I say so often is DevOps is iterative continual improvement. Yeah.

And just bite off small chunks, change change one thing that you can tackle, take on the next thing, take on the next thing, take on the next thing. And, you know, it's not about seeing what you've done in two weeks. It's about seeing where you are in a year's time. You know?

I think that's a journey that resonates with you as well coming from Salesforce admin to release engineering stepping into this Oh, yeah, definitely.

It has been quite the journey, but it's been an awesome journey. I love that about Salesforce because the world is so expansive and it is changing and seeing AI and Agentforce and all the things get introduced to it is making it change even more.

But it's fun to see that change and kind of see where it's going to go.

Yeah, absolutely. And I'm curious also to get your perspective on what does success look like from your perspective for your Salesforce team?

Oh, oh. So for my team specifically, success, I think, really means delivering predictably and safely. So what does that mean? Literally knowing what's coming down the pipeline a day or two before our release days, our release windows are predictably every Wednesday, without having to jump through all these hoops.

So, obviously, being a public company, we have a lot of approvals that we need to go through, and it's well structured. So we we know what we need to like, all of those goalposts we need to hit before we actually release something. So if myself and my counterpart can get everything approved and ready to go before Wednesday and everything is validated successfully, our release is ready and Gearset, you know, I think we are checking all those boxes. And for me, that's awesome.

Sure. I think I can be superwoman and a firefighter and team janitor all wrapped up into one when I have to be, which I I do often. That is that is I think people who know me know that. But I'd rather not have to be stressed out of my gourd every day, or every week because that's that's something that is just know, it's not cool as a release engineer.

But I think the other thing too, and I had this discussion recently with another teammate, is trust. If our stakeholders can trust us and, like, when they trust us, they trust our team. They trust our process, and they know that our changes are their changes, excuse me, are gonna be delivered, with no defects, and they've built something excuse me, we've built something sustainable. So they know they can trust that their stuff is shipped and they can just take a breath, a sigh of relief.

And I think that is really the best success that you can achieve, especially from a release perspective. And it sounds boring, you know, that predictability is a thing, but I think it's okay.

You say that and you know what?

Boring is good sometimes. Predictability is a wonderful thing, but come back to what you said at the end there, like trust.

Trust in your team from your users really is something that I think a lot of Salesforce teams can sometimes get caught in, we're building this thing and we're doing the best things since sliced bread like AgentForce or implementing a new Experience Cloud site, or we've built a great flow that's gonna automate this business process for you and make your life a little bit easier. Ultimately, what it comes down to is trust and satisfaction for your end users. And if you take a look at something like Org Intelligence, where you might have planned for two or three days about how to implement a fix, but now you have a plan within an hour you can go and get that fixed to them quicker, then the team that you serve trusts you more.

The team's gonna trust that you can get the things that they need out of the door quicker as well. I think that's a huge thing if we focus on satisfaction of our users. I think for me, that's one the things when I talk about human centricity and we need to remind ourselves that ultimately we're sometimes in a bit of a service business, like we're here to service the business, service our users.

Definitely. And I think also that is really true, especially the larger your team is and the larger the org you serve, because that trust can fall really quickly and rebuilding it can be a really big challenge. So I trust is really one of those foundational bricks, as one would say, for that DevOps life cycle.

Yeah, for sure. And talking of that DevOps life cycle, Ana, where would you encourage folks to look at or how would you advise a team that is looking to make changes to go about it?

Yeah. And you mean in relation to adding AI into it or just generally speaking?

Generally speaking, if it's AI, it's AI. If it's not, if it's somewhere that AI can be used, then great. But if not, something else.

I think really it's just understanding your 'why'.

So why are you here? Why are you doing it?

Because I think everybody needs to understand why you are establishing a DevOps lifecycle process if you don't have one.

Everybody needs to be bought into that why. Everyone from your admins, engineers, BSAs, your leadership, and all of the teams that you interact with also need to be bought into that because that's gonna be, again, that those foundational bricks for lack of a better term.

But I think generally speaking from DevOps, like a DevOps perspective, like a successful DevOps perspective, like it it starts with culture, not tooling.

So it's specifically with AI, like you can automate things so the cows come home, you know. But if your team doesn't have a shared understanding, I think of and commitment to like what success is going to look like, especially at the end three, like, you know, a month, three months, a year down the road, things are going to fall apart really quickly. So if you can get that cultural foundation, understanding that why, I think then, you know, you can kind of take that next step in finding a tool, like gear set, you know, instead of trying to patch over what you might have and just throwing something on slapping a new coat of paint on something that you might have and then trying to fix it after a month or two months, because then you're again just firefighting.

Yeah, And I feel like you may have answered this question. I'm going to close this out here at the end of the webinar with one from the audience. Shandan has asked a question to Ana and Jack. What would be your suggestion to a Salesforce team that doesn't have a DevOps specialist?

Oh, that's a great question. I think it's really dependent on how large your team is. So, my role was pretty new. When I joined GitLab, we did have a team member who was an admin, who was kind of temporarily doing it at the time, but it came up because of compliance.

Again, as a public company, we needed to have that separation of duties. So I think it really depends on how much you're deploying and like really the need of it. You know, if you can have if you have a round robin sort of, you know, thing going on, I know teams that have done that where they have one engineer who is the DevOps engineer for the week, you know, that can work. I think there's just, there's a lot of methodologies that you can apply to it, But does there have to be one DevOps person, is really, I think, the question that you have to start with.

I think if you're a really small team, it may not make sense make sense. But if you're a large enterprise, it probably does make sense to have at least one. Because then you can take some of the burden off of planning from whomever is doing that and you can have it centralised.

Yeah, for sure. Great answer, Ana. Yeah, something that I always like to say is DevOps is a democracy. Everybody needs to be involved and be looked after what it is and It's shared responsibility and it's our shared responsibility to improve. Ana, thank you so much.

Wonderful. Thank you for your insight.

Thank you for your amazing reaction to the Org Intelligence demo.

It's so cool.

Of which, if folks that are tuned into the webinar, you would like to get your hands on Org Intelligence, please reach out to the Gearset team.

If you are a Gearset customer and use Gearset already, hop into the in app chat or anybody that is not, please reach out to us via the website and the team will be happy to help. James, if you can still hear me, thank you so much as well for showing us around Org Intelligence. And Ana, one last time, thank you for your insight and your wisdom and sharing with us all today.

Of course, thanks for having me.

You're very welcome. Thank you for tuning in, folks, and we will catch you again in Q4. Thank you so much.