Join us for the recap of this insightful virtual session: “Three Foundations For A Well-Run Org (& Agentforce)” with Ian Gotts! This session will equip you with the foundational elements needed for a healthier organization, ensuring you’re ready to leverage the power of agents. Don’t miss out as Ian shares his perspective on why you should be experimenting with agents now!✨

Let us know if you have any questions or if you have any requests for our next CAS Come and See Video!

Slide Deck: View Here!

SPEAKERS:

Ian Gotts

Shannon J. Gregg

Janeen Marquardt

VIDEO TRANSCRIPT:

Good morning everybody, and welcome to three foundations for a well run org and Agent Force. Super excited to see people from all around the globe. Today, we’re experiencing different moments of our morning or afternoon, and it is a Friday for all of us, which is thankful.

Janeen, I’m so excited to see your smiling face this morning, and excited to hear about your Trailblazer group. Thanks for having us and letting us co-host this. As you may or may not know, Ian is a co-leader with me and Belinda Wong in the San Francisco Bay Area Architect Group. And so, of course any opportunity to have Ian speak to anybody has gotta be an opportunity that we widen the net and let this team know as well because everything he has to say is brilliant and interesting and so very useful to us. So, I definitely wanted the chance to involve our group as well.

And thanks for hosting and thanks for bringing him in to talk about the amazing things that they’re doing there. Fantastic. Thanks for thinking of it. I was glad that the three of us actually all got to see each other in physical form. Yeah.

At the two innovation summit, which was a wonderful couple of days. That’s great. It was really great. I came away with a lot of learning. As did I and you and I don’t really get the chance that often to be in person, which is. Really funny and for as often as we interact on, in different ways, on different things.

So it was really nice and really appreciated your participation there as well. So I look forward to us interacting for more reasons and on more things. Love it. One of my favorite things about the Salesforce ecosystem is the community. I love how communities gather around and thank you to you and Ian and Belinda for bringing your community in To meet up with the Life Sciences Virtual Trailblazer Group, this is a fairly new Group.

I encourage everyone to join. We talk a lot about specific needs in regulated industries, so while it does have life sciences in the name, I think we all know if you’re dealing with a regulated industry. The requirements are basically the same.

They might have different alphabet soup in front of it, but it the needs are the same. I co-host the, this group with Sofee Keener, who is joining us today from Rainy Orlando, Florida, and I hope that sun picks up because I’m headed down there myself on Sunday!

Excited to have you all on here. I see a couple of you have thrown your LinkedIn links in the chat. Please feel free to jump in there and. Make things really interactive today. We are so excited to hear from Ian tz, who is looking forward to your participation. We are going to be discussing three foundations for a well-run org and Agent Force. So Ian, with no further ado, I’m going to hand it over to you!

Thank you so much. Also thank you for all the kind words about people going I could listen to you all day, which is I think quite staggering anyway, so, first of all, this is being recorded, so anyone who doesn’t get it or wants to re-listen to it, then obviously you can see the recording.

I will also share the deck and also a bunch of resources at the back. So, I also wanna try and make these sessions actionable. So rather than just going, oh, I, yeah, I heard him talk, but actually I can’t do anything with it. I really want people to be able to take action at the end. So therefore, some various links will be at the end to Trailhead badges and other things that you can go and do.

So I wanna start with three myths really. The first is people saying, I’m not really ready for agent force. And the answer is no, you’re probably not. But then again, none of us are we all need to be ready enough. And I think part of the issue is that Salesforce orgs are actually in a state where maybe we need to do a little bit of cleanup.

So therefore. You will never be ready. You’ll, we’ve all just gotta get started and chip away at outta the orgs. That’s the first myth. The second myth is people are, oh, agents. It’s all about data. Yeah, data is really important, but it’s not just data to make agents work. And the third myth is. AI just knows your org or just knows your business.

You don’t know it. What chance does AI have? So, we need to get beyond that and actually go, okay, what does it really take to build agents? So I wanted to, I, there’s lots of presentations we’ve been doing about how you build an agent and you can find those online. And again, if people have got questions, I can go into that.

But I wanted to think about some of the foundations and things that we could be doing. If our organization says, oh, we’re not ready for an agent, this is the opportunity to use that as a catalyst to go. We need to do some things to try and clean up the org. So that’s what I wanna spend some time talking about.

As Shannon said, if you’ve got questions, please throw them in the chat. I’ll try and keep track of it. Or Shannon, you can or Janine, you can keep me honest. So let. So just for those people who haven’t built agents, this is a agent force 1 0 1. This is the anatomy of an agent. You have an agent.

And by, by the way, all agents, whether you’re looking at Microsoft copilot writer.com crew, ai, ServiceNow, all have a similar sort of structure. ’cause an agent works in a similar sort of way. The only thing that’s slightly different with the agent force itself is we have the idea of an agent and a topic.

And a topic really is the agent level. So a topic or an agent is, has actions, things it can do. I post a record summarize some text come back with a information from a vectorized database call an API and. It has instructions, things you’re trying to explain or to explain how the agent should work or how it should make its decisions.

And below every action as said, it could be a workflow, it could be Apex, prompt ai prompt which could be doing various things. A prompt template. It could be an API, and we’ll see that list of things that they can do is will increase over time. And the important thing to do to notice is this, is that group is how you deliver a job to be done.

So, a job to be got done could be summarize a call, pull out the actions, and schedule some meetings. It could be check availability for me to be able to take PTO and then book a PTO record and then notify my supervisor to be or my manager to go and get it approved. So I think when we think about agents, don’t think about, oh, I built an agent because I built a prompt template behind a button.

Yeah, that’s part of agent force because it’s ai, but that’s not an agent. The power of an agent is to be able to do multiple things a series of things in a number of steps. So I’m not denigrating or saying, being able to build a prompt template that summarizes all of the account record. That’s really valuable, but an agent can do so much more.

It could summarize that that call. It could then work out what it could then go out to maybe some news groups to go and find the latest news or the latest industry news that is relevant to that client. It could then go and get the LinkedIn profiles of the people who you’re meeting, summarize all those together.

So think of agents as almost multi-step, and we haven’t even got into agents, meeting agents. Someone’s just posted about a vector database. Yeah, so the, one of the powers of agent forces obviously is data Cloud and data cloud for a couple of reasons. One, it could be because you are aggregating data from third party systems and making that available to the agent, so the data cloud.

Data data appears as essentially a custom object inside Salesforce, and therefore you can use workflow or Apex or a prompt template on that data. But the other feature of Data Cloud is a vectorized database, and what that means is you can dump into it unstructured data PDFs various documents.

It will then. Data Cloud will then and Agent Falls together, will then chunk it up so you can then ask questions a bit. So that is obviously, that’s one of the most obvious of the use cases, which is a frequently asked questions. So let’s dump all our HR policies into a vectorized database, and then our teams can ask questions about HR policy.

So that, that’s a one of the, probably the easiest and simplest use cases that I’m seeing. So if there are mo no more questions or any thoughts about agents I could spend the next half an hour talking or just talking about agents. There’s lots of content out there. So I’d like to try and get into like, how do you use the fact that every organization is gonna be thinking about agents to is the catalyst to go, okay, how do we start to clean up the org?

And then what do we need to think about?

So if we think about. The way that we hire staff, the human life cycle, we have a job spec. We recruit, we onboard, we train, and then we monitor and we coach them. And if they’re performing well, we promote them. If they’re not performing well, we, there’s either we let ’em go or we we make sure that there’s some training so that they can pick up the skills they need.

And if we think about digital labor as an equivalent to human labor or it’s a supportive, then we’ve got a similar sort of lifecycle. We’re gonna design an agent, we’re then gonna go and build the agents, and then we need to think about how we govern it. How are we monitoring it? How are we actually giving it more skills?

How do we actually maybe we actually it’s obsolete because we’ve got a better agent. We’ve built a better agent. And I think at the moment, everyone is focused on build. The design phase place is really important because we need to think about what the agent is going to do. And a week ago I saw that there’s a Trailhead badge called agent force agent planning, which is great news, and it’s talking about the importance of thinking about the business process you’re trying to implement.

Yay, Vanessa, you and I are finally, we’re finally breaking through in terms of getting people to think about business analysis before they start building. But there’s also the whole governance piece. How are we going to manage these agents? How are we gonna make sure that senior executives are happy, the agents are performing well?

How are you, how, what are we planning to do in terms of monitoring some of those agents? So there’s a little bit more to an agent and simply the build piece, which is what Salesforce seems to be spending a lot of their time talking about. Couple of interesting things. We have a process diagram that is called digital onboarding.

Digital employee onboarding. So we actually think about how we onboard an agent and we’ve got a process map the same way as we think about onboarding a human. Now, obviously there are different steps, but there are some clear parallels including one process step that says, think about how we restructure the business and now we have agents.

So that’s the first data point. Second one is our org chart for Elements. Cloud has got agents on it, not replacing people necessarily, but the supporting people. And you go, well, isn’t that just like that? That’s just playing games? No, it’s really important because if for some reason we, that agent product we’re using, ’cause we’re not just using agent Force, we’re using a number of products.

If that product doesn’t exist, what did it do and how do we replace it? What, how, what exposure do we have to certain products that we look across our organization? So there’s a little bit more than just, oh, I built an agent. No, that actually you are now essentially hiring a digital employee with all the responsibilities that you’d have if you actually hired a real employee.

So let’s think about some of the foundations for trusted agents. So if you’ve got agents and agent force at the top underpinning it, you’ve got a bunch of things you need to do. You need to understand the business processes that your agent is gonna go and follow. Because your agent doesn’t just know your business.

You need to try and work out what that what you want the agent to do. You wouldn’t hire an employee and a new intern and go they are, there’s the phone. You probably can work your way around Salesforce. Off you go. But you’d actually want to, you’d have a requirement spec job spec. You’d actually, when they came on, joined the company.

Hopefully you give them some sort of onboarding about what you want ’em to go and do, and that’s the processes. The other second area is obviously data governance and data quality. And again, everyone’s talking about data quality, not data governance. So it is all very well, you’ve cleaned up the pond, you’ve got rid of all the all the pollutant that’s data quality.

But if you’ve still got a polluted river running into it, then you’ve got a never ending task. So understanding what flows into that pond. Which rivers we, and where they’re coming from is data governance. And I think we need to focus on data governance first and then data quality. And then the third one there is well-documented metadata, which is if we don’t understand those flows, those apex classes they, if you don’t understand and know the APIs and how they’re being used, then we can’t reuse them if we use a flow.

An agent and then use it in another agent, and it’s not documented, someone might change the flow and suddenly the agent changes and we have no idea the of the implications. If a flow breaks inside our org, someone shouts and goes, it’s not working. If a flow breaks for an agent, does the agent just work around not having that flow?

I’ve no idea what the action is, and we may never know. And again, if the agent is employee facing, we’re likely to be told. But if the agent is customer facing, the customer may go, actually, I’m not gonna tell you. Or, Hey, flow didn’t work, but it gave me a way bigger discount. I’ll happily take that discount.

So again, we need to be very clear about how that works. And at the bottom, I’ve said agile and governed implementation life cycle. I’ve realized people are going, oh, agile versus waterfall. No, able to move quickly. What we’re seeing is that agents, we need to iterate through those relatively quickly but we also need to have a governed life cycle.

So unless you’ve got good implementation a good implementation methodology, you’re gonna struggle to actually keep pace with the speed that agents need to change.

Okay. So let me pause there and see if there are any thoughts or questions.

Can see people putting things in the chat, which is fantastic. Okay. All right. I’ll keep going. Oh I actually have a whole handful of questions, but I’m not sure if they’re gonna totally derail conversation and I should wait for the end. No, don’t wait. Try ’em now and I’ll let you know if I’m gonna pick them up later.

Okay. Some of these are around, like I have a, what I think is I have a belief system around how I think you should be used, and then I see people doing them a different way. And I think maybe I’m wrong. So for example, even back on the other slide, this idea of jobs to be done maybe it’s because we’ve only ever seen simple demonstrations.

But let’s take something that we maybe all have a ba a basic understanding of. I think, well, let’s see. The example that I’m gonna use is this. So somebody creates an agent and it’s the, I need to request PTO agent in my org. And I’m like, okay. But that’s one thing. Why wouldn’t I just create an agent that does all things hr?

Why wouldn’t I create an agent that I can get instead of having a bunch of different agents? So one, one does request PTO and one says, tell me about our company holidays. And one says, tell me about our health options. I don’t think these are different agents, if they’re all HR related. I think I would create an agent that can answer any questions that I have about HR stuff.

And when I ask a question like, what’s our PTO policy or what are our. Different medical options that somehow that agent would understand where I’m going and go in the right direction and answer the right question, and I would go from there. Or are those, is each one of those topics a separate agent?

Okay. So, okay. You’ve now bumped into the issue that Salesforce has created by this concept of work, calling it an agent versus calling a topic, okay? So you are absolutely right. All of those things you said should be part of one agent. Okay. That’s what I, and that was my assumption. Okay. But the way that they are organized is by a topic.

So a topic is a job to be done. So a topic could be schedule my vacation could be cancel my vacation. Yes. Another topic could be tell me what’s my open balances. So they are all skills of the agent that are associated with vacation planning. You’ve got another set of skills which are, say recruitment skills.

Posting a job, rec, rec writing me, helping me write and post a job rec preparing me for the interview, doing some interview prep training. Another set of skills could be about policies, HR policies expenses, policies. I, it help. So think of the agent. In Salesforce’s terms, which is maybe the internal agent or having a month number of topics.

And then you need to think about how you architect those topics. So that the agent doesn’t get confused. So it’s not 700 topics, it’s maybe 10 topics or 15 topics, but it’s not one topic. Well then is it, instead of my agent being, would it really be like schedule, schedule a vacation or cancel a vacation, is it.

Vacation planning where one action is schedule a vacation and one is cancel a vacation. What’s that level of granularity when we talk about the topic and actions? Because I, because again, if I think about an HR agent and all of the possible things an HR agent might do and all the different topics within a, a company, there’s a lot of possible topics, even at an, when we talk about hr, nevermind we start to talk about like legal or life sciences or, I’m gonna get out of my depths with examples, but, okay. Lemme try and answer those, Janine. Okay. So this is how we structure our internal facing agent.

We have a top level diagram, which has all the skills, agent force, assistant frequently asked questions. I’ll make this a bit bigger so people can read it. HR, vacation. HR recruitment, it help sales coach and technical and case escalations. And these things aren’t even necessarily related to each other.

These are the skills of our agent. Okay, great. If I then go down into vacation assistant, these are now the topics I can bigger so you can see it. Book a vacation, doing a happy dance tech availability check current bookings. Then if I go down, so this is not, this thing does not exist in a agent force. The top one does.

’cause that’s the agent. But these are the topics. So now that is a topic that is the, essentially the steps you go through to book a book, a vacation book, PTO. So by book vacation, this isn’t take me on holiday somewhere. This is, I need to book three days into my Salesforce system to say that I’ve taken time off.

And it’s not actually, it’s not just an action. You think about this, there’s quite a lot, goes into booking a you booking PTO, which is okay, is it a working day? You can’t book it for a public holiday or a weekend. Do I have enough balance left? Is it, have I tried to book it in the past? Oh, I should have booked it for last week, ’cause I was off last week.

And then book it and approve it. So the yellow things are actions and the the purple ones are instructions and then you’ve got some guardrails at the top. And that’s how we’ve thought about an agent. So that is the book. So that’s one topic. Okay. So this is what my brain, this is what my brain has been telling me how this is done.

And this is. This is what I think is how this is done, but trying to explain this to other people has been challenging because the people I think, are building agents where the entire agent is book a vacation and I’m like, I know. I know. Like we’re gonna go nuts. It can be. Sure it’s the first. Okay, hang on.

It can be because an age, if an agent only has one topic, the first thing you do is book a vacation and then you go, what other skills should I give it? Alright, I’ll now start adding more topics to give it more skills. But the problem is going, I think this I am. I’m gonna have one agent, which is just book of vacation.

No. The agent is far bigger than that, but we’ve only given it one skill at the moment. We’ve managed to get it to book a vacation. We’ve got one topic. We will now start adding topics. The important thing is to have some idea of the architecture of how this is all gonna work before you launch into it.

Oh, planning. Did somebody say that’s the problem? People have launched into this now. I’ll go on I’ll stand on that soap pop over here for a moment, which is at no point should is having a well architected team. More important what we need, the central body, who is so the architect, best practice for how to build agents and get yourself organized.

And sadly, those people got disbanded at a point when they’re probably the most important because at the moment. Best practice is actually distributed around lots of different people, and I’m seeing outta Salesforce I’m sure I’m not talking outta turn, different people doing different things, which are all, they’re going, well, this is best practice, but you’ve just built a product that isn’t best practice.

And these guys over here have found a new way of doing it, but no one else knows assets. So there’s no central organizing body at the moment in Salesforce to say. What is best practice and interesting, I’ve got a, I’ve got a day in San Francisco next week after next, which is called the Best Practice Day, and I have no idea whether I’ll end up punching someone at the end or spending my whole time biting my tongue or no, I can’t do that.

I’m me in, I won’t do that. But the point is. I’m not sure that’s the 23rd. There is best practice. And the other thing, it’s moving relatively quickly and I understand the problems that Salesforce have, which is there’s now best practice and now all the Trailhead badges are outta date and someone’s gotta go back and re-engineer all the Trailhead badges and the challenges.

It’s not a straightforward type and it’s moving so quickly. And there, there’s new product coming out all the time and there’s a little bit of right. We’ll throw it out there and see what happens under the banner of Safe Harbor. And the answer is we need a bit of stability and confidence here.

Sorry, we’ve taken this down a completely different track. The point is, and what I should say is, just if I can bring it back for one second, I think the important thing to understand is that once you build that one agent that does that one thing, and then you wanna add other things to it, is to recognize that you don’t need to go build another agent, that you need to go and add another topic to your first agent.

Correct. Not without planning first. To get that message out to people, to help people understand what is the best practice around agent building and expanding on your agent. Again, not without that planning process, and the planning process is critical, crucial, et cetera, and I think that I feel like I’m banging my head against the wall, screaming into the chasm, et cetera.

For this, if we only had a team that was central and broad and could help us get that message out. I implore my fellow architects and people here in the community to help us, to make sure people understand what is the best way to do these things and how we do these things better. That’s why we’re all here, is to learn those things and to help each other to get those messages that otherwise there’s gonna be, we might build 400,000 agents, they’ll just be 400,000 useless agents, and that’s not good either.

That’s a good point. J there is a trailblazer there, there is a slack channel for agent force, so I’ll make sure the link’s in there. Be careful. Yeah, so that’s all that We’ll make sure that is not, that’s public. Anybody can join that. Yes I don’t recommend it at the moment.

Feel free to ping me directly and I’m happy to talk about this. Shannon’s also laughing. We’re working out some kinks still. But feel free to ping me directly and we can talk about some stuff and things will get better. And they’re starting to, but they’re, we are starting to work through best practices and as Ian said, they’re moving really quickly.

But what Ian is doing here is a huge part of this, and we’re working to help bring this in to more and more places and more and more people. And I think the more people understand this planning part of it and the thinking through this process. And really big concepts like your agent doesn’t have to just do one thing.

Your agent can do lots of things. I think that’s a huge thing that I don’t know that people really grasp because they’ve only ever seen agents do one thing in demonstration. So yes, everyone just take that in for a minute. A lot of the agents that have been built for demo purposes rather than for real world.

So the ones you are seeing here on, on screen, we have built, they’re in production. So that’s the other point is you can get agents in production. The statistics I’m seeing at the moment is about 10% of agencies that get built actually make it into production and Yeah, exactly. And it’s for different, it’s not because they don’t.

It isn’t because they don’t work necessarily, is the fact that you can’t demonstrate that they work. Okay. If you don’t have, let’s just do this thing again. Let’s go back to here. If you don’t have a document like this where you can explain what the agent is doing and be able to have some governance, which is okay, I can show you the change log and I can see, and I can show you how I tested this, then no senior exec’s gonna go live.

The, so it’s not, we haven’t got a technology issue. We’ve got a confidence issue and I think the building more ency type stuff is not gonna make it better. We actually need better planning documentation the same way as you would, you wouldn’t just say someone your developers. I’ve got a bit of an idea for an application I need for booking my vacation.

See what you can build. You would think about it. You’d write a specification, you’d have user stories. We seem to have forgotten all of that, and it’s those things we actually, and the diagram we’re looking at here is the planning document. It’s working out which things are instructions purple, which things are actions.

Wow. I need four actions. Interesting side note here. I’ll digress. As usual, ensure the start date is a working day and not a ne not, and not the next working day. Agent force doesn’t understand the word current next, today, tomorrow, because the trust layer strips those out because it thinks it’s prompt injection.

So we had to write a flow to work out what day of the week it was. So you’ve got things like you need to think about, okay, we needed to build a flow here to work out if the date was in the past. We need to write a flow to go and work out whether the person’s got enough vacation. You can’t just do that on the fly.

You need to think about how it works. You need to think about, okay, well what happens if they haven’t got enough days? Do you just say cancel. So what, what happens? So you’ve got the happy path, but you also need to think about the o the other roots. So, so good question. Is there documentation?

Yeah. We built a, well, we built a sort of little training course for how you built these things and the level of a, of elements to be able to build these diagrams and also spit out. I need to be in edit mode, and it will automatically generate the instructions for you. So if you draw the diagram properly, it builds all the instructions.

You stick straight into agent builder. And it will also generate not the test cases, but the scenarios. So think about we’re not testing like test center tests. Does this action work? I don’t care. I want to know whether it’s gonna work, what the different scenarios I need to take my agents through my end.

Think about user acceptance testing. So what this thing will do is it’ll look at all the potential paths through this. Diagram and it’ll build you a bunch of scenarios that you can test. And what’s interesting is people look at these and go, oh no, I didn’t expect it to do that. I’ll fix the diagram before I actually turn it into an agent.

It’s not live yet, but the right hand panel we’re gonna hand, we’ve got essentially a grammar spell check for the diagram. It will check the diagram will work as an agent. Well, think about, I know we are massively off topic now, but I think we’ve got people interested in asking questions here.

If you think about the way an agent works it is not really a flow. It’s simply going, have I got to a point in the discussion where at the start data’s been approved, I. If so, I need to check all the dates in the same calendar year. If I’m at the position where I know the star date’s a working date.

So think of it as input and action, and the agent is looking for to hear, okay, where am I? What am I meant to be doing? What am I meant to be doing next? If you’ve got two boxes where the input is called Start Data Pro approved. You’ve written instructions that say something to do with start date, and you’ve written two instructions that both say if you’ve got to the start date, the agent’s gonna go, I dunno which one to do.

And immediately you’ve inject, you’ve increased a lack of reliability into the agent. If you didn’t realize that, you’re just gonna keep on writing more instructions and more instructions, and it’s just gonna get more and more confused. If it doesn’t work, come back to the diagram and go, oh, okay.

I’ve got two, two inputs that both say start data proof. I understand why it’s confused. The diagram is so valuable of to look at and, but for a number of reasons. One, you can use it for planning you can use it verb testing. It’s governance because I can see all the previous versions of like how it changed over time.

But most importantly, I can actually demonstrate to my senior management, this is what you asked for, this is what it’s doing. This is why we can now go live. And the lack of deployment, the 10% deployment is not because people don’t necessarily have a bad job building agent, but they got lucky or it works and they can’t demonstrate to anyone that it works and therefore the level of risk is considered too high for it to go live.

One of the things I was gonna talk about is there, would you get in Waymo those people who’ve been in Waymo’s? I think we, we were, we got in one in Phoenix and we whizzed around. It’s quite impressive but why would we be happy with the Waymo? First of all process there is actually, we understand what the rules of road are.

We know how roads work. We can see that the Waymo is actually. Obeying the rules of the road. And we also know what we’re trying to do. We’re trying to take me to a particular destination. What a Waymo’s doing is actually really simple. I know what achieving, it’s really hard, but what it actually is trying to do is relatively simple, which is, I’ve called it, it needs to get come and come and collect me, and then take me to wherever I need to go to based on what I’ve asked for the data.

When we think about the three things, process, data, and. We know the roads work the accuracy of what the roads are, how road signs work, all of that is all well known and it’s accurate. I. And in the metadata, how all the stuff about how the car works, so the autonomous driving, the way that they’ve made the steering wheel turn and the indicators work and all that stuff is good enough to be acceptable, to be able to drive around.

Does it have, do they have accidents? Yes, they do now and again, but way fewer than humans do. Interesting. I was driving in the city yesterday and behind a couple of Waymo’s and there was a a fire truck going down the other side of the road and the Waymo stopped. Because it wasn’t sure whether the firetruck was gonna cut across us, saw, let’s do, but it must have heard the firetruck, or somehow it knew about the firetruck and it stopped, which I thought was really cool.

And then a little bit later there was another Waymo was about to turn right into our lane from the side road, but then the traffic light went red, so it was across the pedestrian crossing and it backed up. Because there was nobody behind it. And I was like, wow, that’s cool. I didn’t know we could do that.

Okay, so we’re happy. The Waymo’s work, we’ve seen them working. We’ve all been in them or some of us have been in them, but what have you got an a Waymo and all the windows got black. The win, the door’s locked and it said, oh, I’ll unlock the doors when we get to the destination. No, not happy about that.

That is where we are currently are with agents. If we don’t have that diagram, if we don’t have some way of demonstrating what it’s doing. And my fear at the moment is that Salesforce think it’s the problem is not is an engineering problem. And they’re saying we are gonna build agents that build agents for you.

Okay. That’s not the challenge we’ve gotta solve. That may be something that’s valid in a year or 18 months time when we’re all comfortable with agents, but that’s the equivalent of getting in the Waymo with, and it says, I’ve looked at your calendar. I know what you’re interested in. The windows get black, we’ll shut the doors and I’ll take you to where you need to go to.

And the answer is, I’m now, I’m really not comfortable about getting in one of these things so that we’ve got a confidence issue rather than necessarily a technology issue. And Salesforce’s approach of, don’t worry, we built an agent that builds an agent, I think is actually making things worse rather than better.

I noticed that now when you create a new topic. It says, tell me what the topic, what you want for the topic. And it thinks it can go and write all the instructions, by the way, not following best practice, different issue. But it’s creating busy work. So all I want is an empty topic. I know what I want to put in there.

You’ve now given me a description of scope and then you’ve given me all these instructions, which I now have to delete because they’re wrong. Now there is a way around it, which is if I take that diagram oops, not that diagram, and I give it those. It’s interesting, we found if we paste in. Those instructions into the create a new topic.

It actually does a pretty good job, apart from the fact it gives you multiple instructions rather than one instruction field. Again, massively off top off topic at the moment, but it’s, I wanted to bring it back to the things which make AI work in an org aren’t actually that well structured at the moment.

That’s, I think why we’re also having a problem in terms of massive, wide scale adoption of agents is because we’re not really focusing on some of the, we’re not thinking about what it takes to build an agent, and this rush to be anybody can build an agent. The answer is they like they, I know you can in the demos, but as Janine said, we are not in demo territory.

We’ve gotta do things which work for real and make a difference. And we’re building really complex agents now. 26 steps. Six, six actions. Doing quite complex things being built by Elliot who Elliot’s been building agencies his entire career because he graduated from university five months ago and that’s all he is been doing.

And he and Megan’s been in the company about a year. They’re the people who are building agents and because they’re following this sort of structured approach. I’ll pause there for any other thoughts from other people.

Someone says they don’t trust Waymo’s. It’s quite funny. You don’t wanna be behind Waymo’s in, in traffic in San Francisco because they’re so polite. Everyone cuts them up and they won’t pull out. So yeah, it takes longer In a Waymo in San Francisco I was staggered by Phoenix because the traffic’s a lot faster.

I was staggered by how fast they go around corners. It’s oh, okay. Okay. Let’s just keep going. Okay. So this idea that I, AI knows your org I think the problem is the levels of technical debt we’re seeing in orgs. So 51% of all custom objects are never used. So if AI knows your org is, you’re gonna be confused or disappointed.

By the way, these numbers, we analyze about 1.4 billion metadata items a month. So this is some of the data coming out for what we’re seeing in orgs. So 51% of all custom objects never get used. What’s the other number? 43% of all sta custom fields on a standard object never get populated, and that number goes up to 80% when you start looking at some of the core objects.

I noticed that you can now have, they’ve upped the limit from 500 to 800 custom fields on an object. The other number I didn’t put in here is standard number of average number of fields on the opportunity page layout 175. So, the idea that your org can just work out which field it’s gonna use in an agent is at the moment, just not true.

Use the agent, use the industry fields. Yeah, we’ve got four. Which one do you want us to use? And we’ve got data in all of them. Those are the sorts of technical the issues we’ve got around metadata. So the first thing is, do we even understand the business processes? You don’t need to document your entire business, but you do need to document the bits you think you want to identify.

So use this as the catalyst to go. If we’re gonna put agents into the, and the support, let’s go and understand the support process processes. Let’s document them at the same time, we can improve them. Because we work out what best practices around say, support, and then we’ve got a decent basis for moving forward.

And you’ve seen some of these the idea of a a business process diagram. This is UPN, it’s the standard approach for Salesforce. There’s training courses on it, not difficult to do. Starts with a verb, has inputs and outputs, has resources. Then if you want more detail, you drill down. This stuff is not difficult to do, but it’s a skill you need to master.

All the things I’m talking about processes, data, metadata, they are skills that you need. Many people haven’t really mastered because Salesforce lets you get away with it. You can build a pretty poor org by not doing this stuff. So, yeah, you need to get, these are some skills that you’re gonna need to get good at in the new world of business process in the new world of agents because AI will be able to do some of the junior admin work, but it’s not gonna be doing, able to do some of the analysis work yet.

So that this is one thing which is understanding business processes. The other thing associated with processes is when we start looking about data is, okay, do we understand? Could we draw data models? This is a data flow diagram. I could find an ERD for you, but some of those skills about understanding the data building the data models and then as I think Janine posted, people like there are applications out there which will help you assess the data quality, but let’s assess the data quality on the data that we really care about and that we use.

So this is a data flow diagram drawn using the standard Salesforce notation. If you go, I don’t understand what that means. You need to go and learn how this stuff works. Because this stuff is gonna be critical. That’s a data flow diagram. I’m sure I could find you in ERD as well. So an entity relationship diagram, and again, if these are terms that are new to you, these are gonna be the things which will be important for your career moving forward.

Because the business analyst is gonna be a critical role. The architect’s gonna be a critical role as AI does more and more of the more junior administrative type Salesforce activities. So we are there in terms of agreed process, and I started talking about data governance which is understanding where the data comes from, this idea of a data flow diagram.

Okay. So how did the data get into Salesforce? It came from Docebo. It was an import. It’s then make its way into data cloud. So this whole concept of where’s the data flowing to and from. So again, that this diagram is a, it’s a standard Salesforce diagram, standard diagram, just conscious of time. So let’s just keep going.

Well documented metadata. Okay? The number of times I present and go, who here has got a metadata dictionary? And everybody looks like I’ve got two heads. Okay? How on earth can you manage metadata if you haven’t got some way of actually accessing it? So again, it doesn’t have to be elements, but the idea of a metadata dictionary where you’ve got all of your metadata in one place you can get to including or your agent force metadata.

Including all your data cloud metadata, ’cause this is all stuff you need to manage. And understanding the dependencies associated with all these things is really important. Otherwise, the, you send no chance of going, if I change this flow, oh it’s gonna break two agents. I didn’t realize that, oh, it’s gonna break our, a critical process that we’ve got.

So not having any of the metadata stuff in place is critical. I’m gonna spend a just a minute on a two on something which is, we’ve been working on for eight years and we finally got it to work, which is if you had all of that metadata and you’ve got these diagrams we love, could an application build the diagram about how your org works and it can.

So we built something and we Barry, this is. Is it an agent? I can’t, well, it is a bit, there’s 5% of it’s ai. There’s a bit at the front end, which is ai. There’s a bit at the backend, which is ai, and then there is an enormous amount of code in the middle. The spec for this was 60 pages long. So what it does is it says, okay, which org are you looking at?

Which, what’s the name of the diagram that you want to go and create? And then just ask it a question. How do we manage sales? How do we manage opportunities in the sales cycle? It could be, tell me how I do tech support, or it could be how are commissions run from a finance perspective? Whatever question you want, it will then work out which objects are relevant.

In this case, the opportunity object, it will look at all the, pick this fields and go, okay, well, which, how would this get launched? So we’ll do it from the A sales perspective. So stage, what are the active processes where we’ll pick the opportunity one, and then. Literally in that time, it builds you a diagram of how your org works.

And it’s quite interesting. This is these are all the ways that you can create an opportunity. And this is actually was our own org and our admin team went no. You can only create an opportunity through a service flow through a through a screen flow. We went no, you can’t. These are all the other ways that you can act.

You can create an opportunity. And they went, oh, there aren’t, it’s a new button on related lists. Oh, we’ll delete all those. At which point the sales team all went, we can’t create opportunities. Why aren’t you using the screen flow? What’s the screen flow? So we built a screen flow, which we built to make sure the data got managed in a certain way and it got validated and everyone was bypassing that because we hadn’t realized.

So if I just, we’ll just go on a bit, make it sort, scroll out a bit. What’s this thing cat? Creating a new opportunity with the screen flow. These are all the people who’ve got access. So there’s an interesting question there was like, why is the marketing team and the finance team able to create opportunities?

Well, there must be some overlapping permissions or profiles somewhere that have given them access, which they shouldn’t have. So the diagram is first of all going well, this is a process diagram, but it’s giving us quite a lot of insights around the data process, around security, about process improvement, about user adoption.

And it is also linking it back to all the metadata in the metadata dictionary. So you can now go and dig in and go, where did this come from? And you get the idea, but the point is, we’re now creating documentation on demand. So there’s a little bit later, now, a bit later in the process, finalize the contract.

So why are we doing all this validation here rather than doing upfront? And again, we can go and look at that validation and go, well, what’s that validation all about? Okay, so we’re doing some sort of validation associated with, zero, which is our accounting system, but why aren’t we doing that up front?

So there are lots of interesting things come outta this. One is, it’s probably the first time you’ve ever seen how your org works. Not how you thought it worked, not how the consultants told you it worked, not how it was designed, but how it actually works. That’s the first thing. The second thing is.

Documentation on design on demand. I’m about to look at the case process to identify it. Well, let’s now a look at it. Don’t dig out some old documentation that’s probably outta date. Let’s just go and create it now and ask the question from whatever dimension we wanna look at the case process.

For technical supports, right? We’d like to look at it for renewals. So suddenly you can look at your org from different dimensions and it draws the diagram. Obviously it’s a live diagram, you can edit it, but I think it’s really interesting that we’ve finally, after eight years, been able to now use AI and a lot of code to be, and all the metadata to be able to start to give some visibility into how the org works, which again.

Whether you’re gonna build agents or not is foundational in terms of a better run org. But in terms of what the topic that this discussion was, can you understand how the org works so you can build better agents? Because immediately I can look at this diagram and go, we could put agents there.

That would be great. We could improve that so immediately, but we understand the implications, which is, oh, by the way, but there’s a flow that we need to look at. Oh, and those permission sets aren’t right. An agent needs a permission. So how, which permission sets do I need to add the agent to? So there’s quite a lot implied in terms of building an agent that you never really get when you just do the demo.

I rather unfairly say, when you’ve done a trailhead bags, it’s like. Screwing four, four legs on an IKEA table and believing you can design furniture from pieces of wood it leaves you almost with a false sense of accomplishment. You’ve gotta dig back in and go back and almost do the Trailhead badge again and go, okay, what actually is happening at each step?

Yeah, get through and get the badge, but then go back and go, okay, well what actually do I need to understand? And how does this all work?

There’s a question there. Can this on demand do. You can ask any question of your org. So, custom object standard objects, industry clouds it doesn’t care. It’s looking at your org metadata. So you’re asking the question and it will then dig around and work out based on the AI bit at the front end, based on the question you’ve asked, it will work out.

It’ll interpret that and work out which objects it thinks are relevant, so it’ll start to coach you. So that bit at the beginning where it said, there’s the question and it works out. In this case, it was just the opportunity object, but if you were asking about commissions, it might pull up a finance object or other custom objects, so it’s not, yeah, the front end. You ask the question, AI works out what that means. We then go and find the right metadata and then build the diagram off the back of it.

A customer said to us, I’ve just spent $500,000 and six months with a consulting firm doing this manually. And you’ve just done it in five minutes. So what does the, what does this mean for consulting firms? Is it killing all their business? I don’t think it is. No one wants to do the busy work of trying to work out.

Org works. No one’s gonna write you a case study that says, oh, cloud Adoption Solutions, they’re the best people at spending our money digging around, drawing doing documentation. You want them to be, you want the case study to be about, they helped us like move the needle on the way that we do customer support because dot.

So I think it’s actually, it’s beneficial. I think if you are a consulting firm who thinks you can make money out of unpicking doing all the the boring work with an offshore team then those days are numbered. I’m very conscious we’re top of the hour. I think this is the important message, though.

We all need to start building agents. And yes, they may be just one topic, something very simple. So it may be just one topic to start with, but that will then be the catalyst for us to go back and look at the things which you need to get right, which is, have we got start in a small area, right? Get the business processes right?

Think about data governance, not just data quality. Then think about the metadata and just document the stuff that you are going to be using. And then more importantly, how am I gonna get that on the implementation cycle? So use that first proof of concept or pilot agent as a way of improving all those different steps and justifying to your management that you can get agents deployed really quickly if you do things correctly.

And use that as the catalyst to try and help improve your org. Happy to take any questions. I’m here for as long as people want, but I’m also conscious that you’ve all got day jobs to get along with. I’m just always blown away by seeing elements cloud. Your tool is fantastic, Ian. It’s really cool to be, and I really I like the point of, it’s all about planning and as a consultant.

The faster that I can arrive at an understanding of what I’m working with, the faster I can get around to solving people’s problems, right? So I don’t see any of this as a threat whatsoever. I see it as an amazing tool that I can use that helps me get that plan built immediately. It’s really cool.

And by the way, this wasn’t meant to be a sales pitch for elements, but because I think actually it doesn’t matter what you’re using, the foundations are still true. Whether it’s I, we’ve, I’m, part of what I’m trying to do is try and encourage people to build and understand their orgs better. Yeah, we build a great application that does it, but if we can just get the principles working then and it is gonna make a big difference.

Yeah, I’m in the same camp the first thing that I always do with a new client or a new partner is map out what’s going on and get an understanding of what the field looks like and then start building a plan about where we’re gonna go, right? Like to your Waymo example, you wouldn’t hop in a car and ask it to take you somewhere without having a map.

A map destination. Same concept with making changes in a Salesforce org, but also Elements Cloud is just super cool. It’s always fun to see if the new feature coming out. So.

I will make the deck available with a bunch of links so some resources, so, so you can go and start. If anybody wants to follow them, there were questions about how. Resources for documenting business processes. All the stuff around the well architected pages are still up. So even though the team has been disbanded, the pages are up.

Obviously over time they’ll get that they’ll become less accurate. But all the stuff they did around data modeling is still up there as well, which is good. And some of the things just around the way we are thinking about how to build agents. I think what’s come out of this for me is that we probably need to be thinking about.

So maybe filling the gap around, well, architected around how you architect agents and some of our thinking around best practice there. Some of the work we’ve been doing with Salesforce professional services and see if we, I mean I’m talking to all the industry analysts and telling them they should be telling Salesforce ’cause they won’t listen to us.

They’ll listen to the analysts that that the industry analysts need to, they need to form a, it can’t be called well architected because that would be, but whatever the equivalent of that would be for agents to centralize best practice. We all need that. Otherwise as Janine said, we’re all shouting into the void all the time.

Fantastic. Ian, thank you so much. Thanks to everybody for joining. If you aren’t already a member of the Bay Area Architects Group or the Life Sciences Virtual Group, please join them both. But on behalf of both of the groups, I wanna say thank you so much, Ian. This was beautiful, and the fact that everybody’s hanging on means that we need more of this.

So, let Jaeen know. Let me know what you want your next. Iteration of information from Ian to because I think we’re all salivating a little bit at what you gave us today, and I think there’s so much more that we wanna hear.

Brilliant. Thank you so much!

⬇️ Join the Salesforce and the Life Sciences Virtual Group now!⬇️