From prompting to delegating: How Salesforce teams unlock real AI capacity

Share with

Description

AI is helping Salesforce teams build changes faster, but the backlog isn’t clearing any quicker. When build speeds up and nothing else does, the bottleneck just moves to review and release.

In this session, Nicole Loney, Senior Product Marketing Manager at Gearset, and Max Vickers, Sales Engineer at Gearset, show how to move from prompting AI at every step to delegating whole tickets, with a live demo of Cam, the Gearset Agent.

What you’ll learn:

  • Why raising your AI maturity without raising your DevOps maturity just moves the bottleneck from build to review and release.
  • What it takes to build your own agent with generic AI tools like Claude, Copilot, or Cursor, from sandboxing and org context to output validation, team standards, and upkeep through every Salesforce release.
  • How Cam turns a Jira ticket into a pull request: it asks clarifying questions, gets your sign-off on a plan, then builds the change.
  • How every change Cam builds goes through deterministic code reviews and the same pipeline, tests, and approvals as your team’s work, and how Cam picks up Flow and Apex errors from production too.
  • Which next step fits your team, based on where you sit on a grid that maps AI maturity against DevOps maturity, from setting up a source-controlled path to production to handing AI more complex work.

Learn more

Relevant videos

Transcript

Alright. Hi, everyone. Let's get started. Thank you so so much for taking your time out of your day to join us.

My name is Nicole Loney, and I'm part of the product marketing team here at Gearset. And I'm joined today by Max, one of our sales engineers, and also, Paddy, who you'll see sat in the background. He's one of our development team leads working on Cam, and he'll be answering any questions as we go. So please feel free. If anything pops up, put it in the Q&A area, and we'll tackle those as they come in. And we'll also save some time to answer questions live at the end as well. So if your question's not answered immediately, that would be why.

But anyway, today, we're here to talk to you about a topic that is at the forefront of every Salesforce team minds right now, and that's how to unlock real AI capacity.

Most teams, as you probably know from experience yourselves, have started using AI in some form by now. And what we're hearing time and time again is, you know, really the same thing that it's making everyone faster, but the backlog isn't necessarily clearing any quicker. And that's what we want to get into today. We wanna look at why that happens, what it takes to get past it, what it actually looks like when a team can hand back or hand over a whole ticket, and you can trust what comes back.

So hopefully, whether you're looking at AI solutions for the first time or if you've already got AI embedded into your processes somehow and, you know, you're potentially just looking for new ways to get more out of it, there should be something here for everyone.

And a super quick note on housekeeping before we dive in. We are recording this session as always. So if you have to drop off halfway through, that's not a problem. We'll email that out to you afterwards.

Cool.

So without further ado, I want to start by quickly setting the scene with the challenges we're seeing today. And, you know, none of these will be surprising.

Probably things you've heard of before, but always good just to set that context.

So every company here today has probably bought Salesforce to solve a business problem.

And one of the beauties of Salesforce is really that you can customize it to fit exactly how your business works.

But that means all of that value arrives the same way as a change, something that somebody on your team has to build and then ship safely.

And it's those two things, you know, the idea of getting every change request out the door and doing it without breaking anything, which is what we're seeing most Salesforce teams spending their lives struggling.

You know, on that one side, you've got the backlog. The business keeps asking for changes, and the expectation is usually that the small stuff goes live really quickly. But in reality, we know those tickets are, you know, prioritized and they have to fit around the big strategic projects that you've already got planned and booked in. So that queue, your backlog, just ends up growing.

Then on the other side, you're expected to keep production stable, secure, and well governed, you know, while you're doing all that. Nobody's getting a free pass because you're busy.

And that's why we're seeing a lot of teams starting to turn to AI or have turned to AI Because the logic is if you can build faster, then you can get through more of those changes within the same time.

Now by this point, we've had hundreds of conversations with customers about AI, as you can imagine. And we know there's a real spectrum on where people are on their AI journey right now and where they aspire to be to or where they aspire to get to, I should say. We found it quite useful to sort of use this visual to help teams to identify where they sit on that spectrum. So starting on the left hand side, stage one here is really doing nothing with AI.

Stage two is where you're potentially working with a chatbot. It's open in another tab. You're asking it questions as you're working.

Stage three then is, you know, more of a copilot sort of phase. You're working with it alongside you. You're still in the driving seat.

By stage four, you're moving more into task delegation. And by that, we mean, you know, the idea of handing it tickets and letting AI go and do its thing.

And then stage five is really, you know, the idea of AI being fully autonomous. You kind of give it a go and it works backwards to figure out the rest and then delivers the change for you.

So what I'd like to do now is to take a quick minute to do a few polls.

And the first question I'd like to ask you all here today is using this spectrum, where would you place yourself in terms of your team's AI maturity today?

And I can see that poll's come up. So, hopefully, everyone can start entering your answers. We'll give it a good sort of another fifteen seconds or so.

Where would you honestly place your Salesforce team today using this spectrum?

Cool. Hopefully, we've got a good amount.

Right. So we've got quite a mix actually today, which is nice to see. We've got, you know, some people still at the beginning of their AI journey, some people majority around sort of that two to three mark, And then, yeah, a very, very tiny amount that's popped themselves at stage four. That's great. Okay. My next question for you then is where do you want to be in twelve months time? So another poll is popping up there for you now.

Where would you like to be in twelve months time on this scale?

Again, using the same numbers.

Give it another sort of ten seconds or so.

Cool. Hopefully, everyone's had the chance to respond.

Great. So we've got a lot of people sort of around the the four, four and a half mark, some at five, which is really, really great to see. Cool. That's really, really useful context. Thank you, everyone.

Yeah. I think, you know, if we relate that back to these conversations that we've been having with, you know, customers on a daily basis, that really reflects actually the majority of our customer sort of conversations as well. Most people are placing themselves between a two and a three, and most tend to be aiming for, yeah, a good four and a half, five.

We've had, you know, a lot of people do still wanna keep a human in the loop, which is totally understandable as well.

But one final question for you before we move on. No poll for this one.

I just want you to now ask yourselves, how are you going to get there? How do you envisage yourself getting from your... From a to b, from your first answer to your aspirational sort of location, if you like, in twelve months?

It's a good question.

Some food for thought to wherever you place yourself, you know, whether today you are a two or a four or anywhere on the spectrum, if you're using AI tool, then you've technically already increased your throughput. You're already building more changes, right, than you were ever before. And the further right you move on this spectrum, the more output you get, which begs a fairly obvious question then.

If the number of pull requests your team opened went from 50 a week to 200, could you handle it? What would break first? What would be sort of the first part part of your process to suffer under that increased load?

It's worth having a think about because volume tends to have a way of finding the weakest part of a process. Right?

And when I say process, this is what I mean. So this is a typical DevOps life cycle of a change, which many of you, I'm sure, are already familiar with. And it starts with planning and runs all the way through to observing and maintaining it once it's live in production.

And a quick word what we mean by DevOps before we go any further because it really is a term that means different things to different people.

And we see and define DevOps for Salesforce teams as, you know, the concept of bringing together people, processes, and different tooling so you can ship changes quickly and reliably. And if you want to do all of that at any sort of scale, you need to have the foundations in place underneath it. You know, you've got to have your Git based source of truth, for example, testing processes, pipelines to, you know, automate error monitoring, that sort of thing.

So wherever you just landed is your weak spot potentially on that previous slide.

It's gonna be somewhere on this life cycle, on this picture.

Because when an agent makes a change, this bit here in yellow, that bit speeds up. The build bit speeds up dramatically, which is the output we all wanted and we're expecting.

But nothing else does. Review, release, operate. There's nothing really there to help you to sort of manage that increased load. So what actually tends to happen is you just move that bottleneck, and it lands here at review and release.

Now in those sorts of situations, that leaves teams either, you know, sort of struggling to keep up with processes.

The the gains that you were chasing never actually make it to production because that time is just now spent at review, Or you end up doing less with your review stage. Things slip, standard slip, and things may end up going out without a proper look, and you only find out on release day.

So the question worth sitting with then is if you build three times as many changes but end up rejecting and reworking half of them, for example, are you actually going faster?

That's actually the fundamental mistake we tend to see teams make, raising their AI maturity or in other words, you know, increasing their AI usage without raising their DevOps maturity at the same time.

And one way to look at this is through this grid here on screen. And we think the path to realizing leverage for your customers with Salesforce really runs through both axes.

So just to walk through the sort of table grid, if you like, Where you want to be or end up is in that top right hand blue corner.

Here, you've got real AI, maturity, high DevOps maturity, so you'll be able to deliver those changes quickly with minimal risk and to a super high quality.

Some teams we're speaking to are still in the, you know, the bottom left hand of this grid, which is totally okay too. You're at the beginning of your sort of DevOps journey, if you like, and the beginning of your AI journey. You're not really using DevOps or AI in your processes. So you've got a lot of gains ahead of you by implementing technology.

Many customers we speak to now are in that top left hand corner. This is quite a significant number of customers actually.

And they're ones with high maturity... Sorry, high AI maturity, but still low DevOps maturity.

These customers are moving fast, which is incredible, but you're also more likely to break things. And one of the key problems, as we all know, right, is that the cost of that tends to be invisible right up until something goes wrong in production.

We believe though, and arguably, teams best placed to start their AI journey are the ones in that bottom right hand corner.

You've done the hard part by this point. You've got your DevOps infrastructure in place, you know, the guardrails and the processes, and those are the things that help you to start using and scaling with AI safely.

So I just wanna pause for a second and again ask you to ask yourself a question.

Where would you and your team be if you were to place yourself on this grid? So where would you place yourself on this grid?

You don't necessarily have to share, but I'd love you to keep that in mind as we go. We'll come back to this thought at the end.

Cool. So if we all agreed then that the top right hand corner of this grid is where you want to be, you know, that accelerating change safely. Let's talk about what you actually need to get there then. Now we firmly believe that you need an agent that's part of a team, not at all sitting off to, you know, the side that maybe one person is using and not something sitting above the team making decisions, but something that's kind of at the same level, you know, in the same team reporting to the same person, the same as everyone else.

Something a little like this.

And what this means is you'd work in the same way with, you know, your agent, your AI as you would with any teammate.

You allocate work to it. You'd onboard it. You know, you'd coach it when it gets things wrong, and then you'd also review whatever it produces.

You'd probably start them small and, you know, they'd prove themselves and the scope would grow. The trust grows through experience, etcetera. So if we start to think of agents as teammates, not tools then, the next obvious question is how do you get your hands on one?

And right now, most Salesforce teams answer looks something like this. They tend to be turning to generic AI tools like Claude, Copilot, Cursor, etcetera, and they're trying to build something themselves.

And to be completely honest upfront, some teams have been able to do this and they've done it really, really incredibly well. And perhaps you're one of them, which is so absolutely amazing. But if we walk through this sort of setup process that we've got here, you'll see just how much is involved in standing something up properly. All the different things you've got to consider, how every sort of line has an impact that happens later if not done correctly.

So going down that build route, that build sort of, process and doing it yourself isn't necessarily sort of ideal or, an option for everyone.

So let's walk through those steps then.

So first, you've got to make sure it's safe to run, which means standing up a properly sandbox setup and then rolling that out to everyone who needs it. Because without that, when you connect, you know, an AI tool to your org or to your repo, it kind of acts who... It kind of acts as whoever you've connected to it. Its permissions are their permissions. It's, you know, running on their laptop with that laptop's credentials and network access. So you then have to assume it can see everything that that person can see. So super important to sandbox it.

Then it needs to know your org. So as you know, not everything lives in sort of your VCS repo. You need that combination of your repo and your Salesforce org to get the full picture.

So you've got to glue all that together yourself. And then the challenge is that connection to your org then tells the agent what your team did.

It doesn't necessarily tell them or tell, you know, your agent what it should be doing, what you've decided you should do. So the agent will converge on your sort of most common patterns, including the ones you're actively trying to move away from, which is something you've got to keep in mind as well.

Then you've got to set up a process to validate the output, you know, checking things like has it hallucinated, different Salesforce metadata? Has it actually generated the correct XML?

And because it probably hasn't, then you need to start writing some skills to improve the accuracy of the AI to help you to catch any issues further or earlier.

And then when you've gone through all of those loops and you've started to, you know, kind of build your own DIY AI tech stack here by this point, you've then got to standardize that across the whole team. So you need to make sure everyone's using Claude in the same way every time because no one wants their team working with with 10 different setups, with 10 different standards of quality.

And then you've got to maintain it through every Salesforce, every Salesforce release, you know, every model change and ensure it still works. And then after all of that, you still only find out at deploy time whether that change actually works.

So that's a lot of steps, and not one of them is the thing you actually wanted to build or wanted to do, should I say, which is to build a change.

I think this is probably more the outcome a lot of people are actually looking for, this shorter path. You've got a ticket with a request from the business.

Then the thing you actually want at the end is just a pull request that's already proven against a real org that you know is going to work to your standards with the same context, the same consistency, no matter who raised that pull request.

So lots of steps to get something set up versus none really.

And that shorter process, that is exactly what we have built with Cam, the Gearset agent. So CAM, if you've not heard, is what we're classifying as your virtual Salesforce teammate.

You can give it a ticket, and unsurprisingly, it gives you a pull request that's planned with your org's context tested against a real org and shipped through your pipeline at the end.

So if we unpack what I mean by that. So CAM doesn't bypass your pipeline. It joins it.

Your processes still decide what ships.

You know, you get the same reviews, same approval processes, same record of what changed and why. So, again, that... You know, going back to the idea of having DevOps and your, like, processes in place, That's why that comes in really, really important here.

CAM also validates its own work before it ever reaches you, which, again, is something that a lot of teams would benefit from because then, you know, you're always handed a change that would deploy.

Plus it works across your whole DevOps process, not just the build stage. And this is, again, super important because as we said earlier, you know, if you're only speeding up build, then all you've done is move the bottleneck to further down the process.

And we've got real teams and real customers using Cam today. I just wanted to spend a second on a quick example from Hudl.

Their Salesforce admin, Jessie, had a project where she needed to update 520 picklist values across 72 record types.

So it's a kind of thing that they said, you know, wasn't actually particularly hard. But because of the sheer volume of changes, it was something that would have taken, you know, Jessie quite a few days to do.

And Cam did that, I think, they said in, like, an hour.

And it, you know, did it in one conversation.

And at the end, it gave them a pull request that they were able to deploy confidently.

So, yeah, pretty incredible how efficient it made Jessie with that one task.

But anyway, enough speaking, enough talking. I'm going to hand you over to Max so that you can now see Cam in action.

Okay. Can everybody see my screen, Nicole? We we good there?

Yeah. All good.

Awesome. Well, thank you, Nicole. And, you know, folks, so now that we've talked a lot, Nicole walked us through some great inform...

Informative stuff there, and you've really heard the why. And let's take a look at what this actually looks like. And I wanna start somewhere that maybe you don't expect from an AI demo. And where we're at is the Gearset pipeline.

This is a Gearset pipeline that every change takes to get from where it's built into production. Each box is a Salesforce environment, and a change moves left to right, checked at every step by version control, automated tests, code analysis, approvals. If you've already got one, probably looks pretty familiar. If you don't, this is what Nicole meant by DevOps maturity, a safe path to prod.

So here are some changes that we can see visually within the pipeline lined up going through review and release. But a fair question is, how did these pull requests or change requests get there? And the traditional answer with Gearset is that a person on the team built them, and that's still true.

But there's now another way that work gets into the pipeline.

Meet Cam, our Gearset agent and virtual teammate, as Nicole had alluded to. And notice where I found Cam at this stage, not in a separate tool off to the side, but directly inside of the pipeline. You can see it here.

As we take a look, Cam is already connected to the same pipeline we just looked at, and it works in the context of the orgs and pipelines that you have in place.

Now as we think about this from a larger perspective, the title of this webinar is prompting to delegating, and this is truly where that shift happens. Up here in my chat box, I could certainly describe a change, prompt it, but most teams already have their work written down somewhere. So instead... And if you take a brief peek below, Cam has actually pulled in my Jira project. That's my backlog already here. No copy and pasting. And, you know, as a sales engineer, this is a question I get on almost every call.

How good do our Jira tickets need to be for this to work? And the honest question is not very. As we scroll through the list and as I understand my own work, I know that a lot of these tickets are detailed in spec, but some are basically, here's the problem. Figure it out. And that's very normal. And you'll see in a minute what CAM does when a ticket's missing something.

And one last thing just before I hand anything over to Cam. I wanna call out the org snapshots here. Cam is always working from a snapshot of your org. It knows my objects, fields, flows, and automations before I ask it anything. That's the difference between handing a ticket to a teammate that's on their own day one and handing it to a teammate that already knows the system.

So what I'll do with my new teammate is go ahead and immediately give them some work. I go through my backlog. You can see the opportunity to filter between stages, owners, and even statuses. Here, I'm gonna pick up a couple of tickets and ultimately hand them over to what is my new best friend, Cam. And, again, before we go, this is all tied back. I'm telling Cam where to work, my pipeline, my dev environment. This is not on someone's laptop, and it isn't touching production.

It works where my team works under the same rules.

And now as we've handed Cam some work, this is Cam's board. It's basically a teammate's to do list, planning, building, ready for review, and even finished pull request visually rendered. Cam works all of these in parallel. And the important part is that question to answer means it's not to ask me something as you can see down below.

Plan to approve means it's not building anything until I've signed off, and changes to review means it's done, and now it's my turn. If I only want what's waiting on me, however, I flip to this, my work and my blocked work. And this toggle, my team here, is the bit that matters at a team level. Everyone sees the same board, the same work, and the same history.

It's not 10 folks with 10 private setups. And you can actually see based off of what we've assigned to Cam already, one of those tickets already in action.

The ticket in question that's raising a question is our sales tax ticket, validating that numbers externally are checked to be correct. And bluntly, if we look at the ticket itself in plain English, the reps keep entering bad VAT numbers on new accounts. It's messing up invoicing, and we need to introduce a change that checks each number as it's entered, flags the bad ones to finance, and doesn't slow our reps down.

But as you can see, before actually doing anything, CAM has done its homework. It's checked what we've already had as we handed off the ticket, understood that there's no VAT fields yet, nothing set up for external tax service, and our finance fields are locked down so that only admins can edit them, all rooted in the context of our environment and working within our pipeline.

And because of all of this insight that Cam is able to gather, it's paused to introduce a line of questioning. The first one being, and it's a good catch, the ticket says to match how other finance fields work, but those are admin only. And reps need to go in, type the VAT numbers in. Cam spots the conflict, explains the trade off, and recommends access for just reps. That's the same call that I would make. So I'll go ahead and make that determination.

Now the second question relates to adding a country field. Cam is going to go ahead and recommend yes, but the country code is already at the start of the number, so I'm actually gonna say no to this one. Third, the encryption. Encrypt the field or just track changes to it.

Encryption is safer, but finance couldn't report on it. So track changes, option one here, is actually going to be my recommended approach and the guidance that I give. And last, how finance hears about a bad number, let's say. A task, an email is the recommended option.

Cam has provided that, and I agree. So I will go ahead and give Cam that proper guidance. And one thing to call out here, four questions all before anything was built and all at once. I'm not getting pinged all afternoon, and notice they are the right questions.

Questions. A generic AI would would guess or ask you everything. Cam knows what matters because Gearset has built over ten years of Salesforce DevOps experience into it, plus your own team standards. You'd otherwise build and maintain that yourself.

We do it for you. So that Jira ticket that left out some detail, this is why it doesn't matter.

Now if we fast forward to this conversation, once we've given Cam the answers it needs and it's comfortable with developing a plan given that guidance that it feels confident in, it will still come back to me but with a plan.

You can view the full details of this plan and see my answers in it. No country field. The reps get their own access, and the external check is a placeholder for now exactly as the ticket asked. The alerts to finance live in a flow so an admin can change them later without a developer, and it's kept the check and the alert separate.

So when the real check is plugged in, the alerts keep working without a rebuild. Nobody asked for that. That is a teammate thinking ahead. And once again, nothing is yet to touch my org.

I review it. I push back on Cam's plan if I want to. But if I'm happy with it, I simply move forward and approve.

Now if I'd handed this to a colleague, this is where I'd go make a coffee so we can pretend that I'd... I've done just that. We've gone back to the assigned work board as you can see here, and the coffee's done and so is Cam.

We now get the opportunity to review exactly what Cam has built or is proposing to build, I should say. We have the historical reference to all of our conversations. We see the steps that it's followed. There's new fields, the permission set, the placeholder Apex with its unit test, and the two new flows, exactly what was in the plan. And I can see every change before it goes actually anywhere.

Now couple things to call out here. This was built by AI, so how do I know that I can trust it? Two things make CAM different from pointing a generic AI at your org, how it's built and how it's checked. How it's built is that CAM isn't a general... One general purpose model doing everything. It runs on AWS Bedrock with an orchestration layer that picks the right model for each part of the job, and it's working again from my org's actual metadata, not guessing.

How it's checked, it goes through the same code reviews as my team's work.

Hundreds of rules aligned to Salesforce Well Architected Framework and the OWASP Top 10 across all of it, the Apex, the flows, the fields, the permissions, a tool that only scans Apex would miss most of what Cam just built, built, and those checks are deterministic. They don't use AI to grade AI. Same rules, same result every time, whoever, whatever built it, so Cam can't mark its own homework.

Now if we fast forward past this review stage, I've checked this work the same as I would for anyone in their first week, and I'm happy, which leaves one step for me, and that's asking the teammate to actually open the pull request as you can see below.

And think about where this one started.

A Jira ticket about reps typing in bad VAT numbers. It asked me the right questions, brought me a plan, built it, got checked. And as we're taking a look, we can actually view in the pipeline here and see that it made it back right to where we started. The same pipeline, everything that Cam... Builds goes through the same governance as your team's work.

Automated tests, code analysis, security checks, approvals. And if something else fails, a test or a deployment error, it goes back to Cam to fix it, and I don't have to chase it.

That's really the point that Nicole had made earlier. It's not really truly about how much AI builds. It's about what actually ships. And as we think about what we've talked through today, from here, life moves on. This gets promoted, as you can see here, to integration through UAT and then rides a release all the way up to production.

But shipping isn't... Shipping it isn't the end of the job. Once it's live, how do you know you haven't broken something?

This is where, Cam...

The honest answer, I should say, is actually that you find out when a user tells you or it's buried in an inbox. If I have just a quick open question for everyone in the room, how many unread Salesforce emails is your team sitting on right now?

Nobody's gonna get in trouble, so no no worries with how large or small the number is.

Okay. Well, this is where I want to introduce you to how Cam keeps an eye on production for you.

Flow errors, Apex exceptions, limits, all in one view. So the moment something starts failing after a release, whether it's something we just shipped or something that's been lurking for months, Cam has already gotten eyes on it. You're not waiting for someone to tell you everything so far started with a ticket.

This is the work nobody files a ticket for, and it's the same teammate picking that up.

If we take a look at the top errors and trend analysis here, this might be a great indication to understand that this weekly invoice flow is one of our most critical, and we can see via Cam that this has fired, impacted multiple users, and has been relatively frequent frequent as well.

That's real people having a bad day. And if you look at the ranking, I went down to number eight. The one with the most hits isn't always the one that matters the most. Impact doesn't necessitate volume.

A generic coding agent pointed at your error emails would burn through the noisy ones and never get the quite expensive one right.

So I hand this change to Cam in the context of my org. It builds the fix, and it goes into the same pipeline through the same gates, the same teammates, albeit a different door.

And that's truly where Cam can go once you trust him.

You start by handing Cam tickets, then you start by asking, what else could I hand over to you?

And as we can see here, while we're waiting for Cam, Cam is going through summarizing, what the issue is, identifying the root cause, and actually proposing the initial build and ultimate remediation, once again, all tied to the pipeline.

Nicole, back to you.

Thanks, Max. Super, super clear as always. And one thing you just said, the, you know, the idea about trust and how you... Once you know what can can deliver and the, you know, the fact that it can deliver to a high quality, the world really is your oyster with what else you can give it. I've got some thoughts around that that I want to come back to in a second.

But first of all, if you guys all remember right at the beginning, I asked you to keep in mind where you would place yourself on this AI DevOps maturity table that we spoke about towards the beginning.

And to wrap up, I would like to spend a couple of minutes just sharing suggestions for some potential next steps for you depending on where you placed yourself earlier.

So walking through the table, let's start in the bottom sort of left hand grid.

Here, if you remember, you know, this is low AI maturity and no real DevOps processes in place yet, and you're at the beginning of your journey.

And if this is you, we'd really recommend your first move is to look at putting into place some sort of source controlled automated path to production so that you can be sure that whatever you do deploy is safe and good quality. And we think it's worth doing that before you try to catch up on AI. And that's mainly because, as we said earlier, AI really multiplies whatever processes you already have. So if you want, you know, to do it well, you need a good process in place to multiply. Without it, you just end up generating volume with nowhere safe for it to land.

And I should have clicked so that the bullets appeared a bit. There we go. Next one.

The next is the top left, as you can see. So this is where you've got quite high AI maturity.

Perhaps you're already starting to use, generic AI tools like Claude or Cursor to build changes, but you've still got rather low DevOps maturity. And perhaps you don't have an automated path to production yet either, or maybe you do, but, you know, you've got no real testing or validation processes in place. Perhaps you've got no way to track errors in production.

You may be feeling like you're moving fast, as we said, in breaking things.

And it's arguably the most dangerous place to be in because it feels good, but fixing things after they've been released is obviously the most costly way to do so.

So your next move then should really be to continue building processes so you can better trust what reaches production and can effectively track how it performs once you're there. So considering things like error monitoring, looking into things like automated testing, yeah, improving your review processes.

Now for those of you in the bottom right hand corner with low AI maturity but high DevOps, you've already done the hard parts. We said you've already got that infrastructure in place. You've got a pipeline. You've got review processes potentially so you can catch issues early.

Maybe you've even got error monitoring set up, as he said, you know, as Max is showing today with, you know, the ability to see how well production's performing. And this is a super excellent place to be before you start scaling your AI because you've got those guardrails in place. So we'd recommend then your next step is to find a teammate that delivers on everything that we spoke about today, and then test it with a real ticket. See how it actually works in real life and let your sort of existing checks and processes judge the result.

And then last but not least, the top right.

Those with high high AI maturity and high DevOps maturity. And you're delivering changes sort of to a high quality and quite quickly.

Now, as always, there is more work to be done. You are not finished either. And what we recommend here is, you know, up until now, you've probably been asking yourselves, can we trust our AI output?

Now we think you should be asking yourself, what else can we hand over, as Max said earlier.

And we've got a couple of ideas around this.

First of all, you know, you can widen the doors that work comes in through. So, you know, not just handing over tickets, but as Max showed, asking it to pick up production errors too.

You could look to increase the scope of work you give I... Give AI, you know, increase the complexity of the tickets and, you know, maybe move towards that sort of stage five, as we said earlier, of, you know, delegating goals.

And then the last one is one I find quite exciting actually. Because if you think about it, a lot of the people giving you work and filling up your backlog are the ones, you know, that are actually requesting the changes in the first place, and then they're waiting weeks for them to land.

Well, with everything we've spoken about today, you know, the likes of tools like Cam that already knows your org. So what it builds is high quality. The fact it can ask questions, so it's, you know, basing responses on what you actually would want to see. And then when a PR is raised, it goes through your same pipeline and the same checks as everything else.

The guardrails are really the same no matter who kicks that work off. Right? And that opens up a really exciting opportunity.

And that's the the people who were adding to your backlog can now start helping to clear it too by potentially using some of these tools like Cam, spreading that work across other people that potentially previously wouldn't have had the skills or expertise to do so.

But anyway, no matter where you are on this table, the real thing to remember is that you can't get to that top right hand corner by just going along the top and focusing on AI. Teams that tend to scale AI first and then try to add governance afterwards sometimes end up rebuilding it. So not the, you know, the best way to go about it. You really need the foundations in place to help you to get anywhere quickly.

But no matter what your steps are or what even your goals may be, we, Gearset, as always, more than happy to help. Whether you'd like to learn more about how we can help you to improve your sort of DevOps processes or maybe how Cam can help you to clear your backlog, feel free to reach out. There's a QR code here on screen where you can book in some time with us.

If you just like to learn more about Cam, our AI agent, then, the second learn more QR code there will take you to our website where you can have a little look.

And, yeah, really, we're always open for a conversation. In fact, we've actually got a little bit of time left. So if there are any questions coming through, we'd be more than happy to answer them.

So with that, let me pull up the chat. Feel free to add any in if you've not had the chance to do so yet.

I'm just gonna get up the Q&A.

Cool.

Alright. So I've got one question here. What's the difference between Gearset's org intelligence and Cam? It's a great question. Max, did you wanna give it a go?

Yeah. Yeah. Absolutely. I'll take a stab there. So in reality, the agent functionality within Gearset, as we think about org intelligence and Cam, it's all kind of a part of the the same agent functionality.

So whereas the org intelligence aspect specifically of it, all a part of the same agent, but used for a little bit different of a use case. Those being...

Maybe you have that Jira ticket that you've given four of them off to Cam, but you have that one that you don't even understand truly how the business process works and you wanna help enable yourself or other team members within org intelligence. That's where you'd go in, you know, ask some questions about the Jira ticket, maybe refamiliarize yourself with how your own objects and automations operate, but ultimately all tied together back into the Cam functionality as well. So, Paddy, not sure if you'd add anything there.

That would be my my stab at it.

Yeah. No. I think that's pretty much covered it, Max.

Yeah. But we see a lot of BA's and analysts using the org intelligence side of the the agent to to to just start, you know, who who maybe aren't responsible for the building of the actual code, you know.

Yeah. Great. Perfect answers. Another question, is Jira the only supported tool for Cam?

At this current stage, I know we're we're changing that one, Paddy. I saw you going, in the comments on it. Jira, right now, I believe, ADO as well. And and we have what coming down the pipe you might be better for the kind of down the road sort of topic.

So I think we are moving towards first class support for all the ticketing systems you can link into pipelines currently, which is off the top of my head, Linear, potentially ServiceNow, potentially Asana, but there may be support for those via an MCP server connection first to allow you to hook into your ticketing system and build it out as you need it.

Cool. Thanks, Paddy. Another great question here. We have coding standards in place that must be followed. Is it possible to get Cam to follow them?

Yeah.

I think the answer there is yeah. Nothing nothing to add in that regard, unless, Paddy, of course, there's some additional context.

Yeah. No. I mean, what you add to yes, other... And absolutely. It's something it's something we're working on. It'll it'll certainly try and infer the standard from what's already in place so you don't have to add too much.

And because it already knows about Salesforce, it's not that you have to tell it how to do Salesforce changes. But, yes, everybody's got some specific things that they'd like to have in place, and we do have mechanisms in place to allow you to do that. We are also looking at how we do that more intelligently as well over the next quarter. So plenty of iteration happening.

That's great.

One other question that I saw come through earlier, actually, Paddy, which I think you answered, but I think it might be nice just to repeat. And it was around, like, the complexity of tasks that Cam can handle.

I just wondered if you wanted to reiterate your response just in case others haven't seen it.

Yeah. Sure. So...

Well, I think the question was, can Cam handle more complicated workflows, like large flows or ideas with that. So I've had the good fortune to be in the number of POC calls with customers over the last six months as we've been developing this. And one of our customers, their task was importing some very large flows from one org to a completely different org and adjusting them for the new org that they were going into.

They had great success with this, to be honest with you.

Almost a surprise to ourselves, to be frank. They they really did extremely well.

I think they'd estimated this work manually amongst the team to run at about three and a half months, and he finished it in a week, created the flows, working through it. Now it was him back and forth with the agent quite a lot. So more exit... More complex workflows require a little bit more prompting and guidance. But because we could do a good job upfront of creating those flows in a sensible structure with a sensible architecture, it made it all much more manageable.

Yeah. Sounds incredible. Doesn't it? When you hear real examples of how it's working.

Absolutely.

Yeah. That's amazing. And I think, one more question that's come through, and then we'll call it because I know we're over time.

Does Cam work with back office?

I guess I'm not quite entirely sure what the question means, but if this means to be able to hook into things like Google Drive potentially or...

I'm not quite sure.

Yeah. Might have to...

I know. Yeah.... Really with back office.

Yeah. We are we are we are building out our support for MCP server connections, so the ability to hook into other data sources.

Yes.

Front office transformation. This may be something that's just... I'm not entirely familiar with, but I'd love to reach out and we can maybe answer this question in a bit more depth with with a chat as opposed to here potentially. But, yes, we're, like, we're working on... Currently on expanding the ability to pick information from other data sources because context is all important for agent work. You know?

Thanks, Paddy. I know I said last one, but there's one more that's come through, and I always like to get them all. Does Cam have access to your data in the org so it can code with the settings you have in your org that lives as data, but not custom setting or custom metadata?

Sorry. I read that as it was written.

Yep. No. Currently, the agent can only access your metadata. It does not have access to the data in your Salesforce org at the present.

We are looking at implementations of things like CPQ and how we deal with that. Currently, that's also work in progress right now. But as it stands right now, the answer is no.

Cool. I think we've got them all. So thanks team. And thank you everyone for staying till the end. And as I said, seriously, take us up. If you wanna chat through anything at all, we're more than happy to have the conversation.

But, yeah, with that, we will leave it there and hope to see you all on another webinar soon.

Thanks, everyone. Thanks, everyone.