Loading...
technologybusinesscareers
Use Metadata to Empower Salesforce Agents
About this Episode
Today on the Salesforce Admins Podcast, we talk to Joshua Birk, Admin Evangelist at Salesforce.
Join us as we chat about why your metadata is crucial for building effective AI agents.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Joshua Birk.
Why multi-tenancy still matters for Agentforce
As the Admin Evangelist team has been helping people get started with Agentforce, we've noticed that the key to unlocking this new technology is to revisit some of the oldest concepts about the Salesforce platform.
That's why I brought Josh Birk on the pod to talk about metadata and multi-tenant architecture. If you need a refresher, that's the idea that Salesforce is like an apartment building where each org is an apartment. Your stuff is in your individual unit, but the entire building shares resources like water and electricity.
So what's the difference from 2010? As Josh explains, it's that every apartment comes standard with an Agentforce-powered robot butler.
Quality data leads to better automation
Imagine you're sitting down for dinner, and you want your robot butler to set the table—how does it know where the forks are? And what happens if they're buried in your junk drawer?
Clearly, a robot butler will be more helpful if you keep your apartment organized. And, as Josh points out, the same is true for your Salesforce org. AI agents rely on your metadata, like description fields and field types, to help them respond correctly and find what your users are looking for.
With longstanding orgs, there can be an "if it ain't broke, don't fix it" mindset, but that's the equivalent of throwing everything in the junk drawer. Doing a little spring cleaning and organizing your metadata helps Agentforce help you.
Why you're already an AI builder
The key thing Josh wants you to realize is that you're already an AI builder. An agent is just another user in your org, and so the work you do to make your data easy to use is also what powers the solutions you build in Agentforce.
That's why it's so important to fall back on Salesforce fundamentals. Building an agent is the easy part. The hard part is making sure your metadata is in a good place to support your AI solutions, but that's the work that admins do every day.
There's so much more great stuff from Josh in this episode, so be sure to take a listen. And don't forget to subscribe to the Salesforce Admins Podcast to catch us every Thursday.
Podcast swag
Learn more
Admin Trailblazers Group
Social
Full Transcript
Mike:
Hey, Salesforce admins. Ever wonder what multi-tenancy AI and your junk drawer have in common? Luckily, Josh Birk is back to explain it all, from forks, to metadata. Yeah, we even throw in some robot butlers. This episode's a ride through the architecture that makes Salesforce magic happen with, I promise you, enough analogies to stock your kitchen. So, if you've ever said, "Wait, where are the forks?" This one's for you. And when you listen to it, that sentence will make sense. So give it a listen, send it to your friends. Be sure to hit that follow subscribe button to get brand new episodes downloaded on your mobile device. And without waiting any longer, let's get Josh Birk back on the podcast.
So Josh, welcome back to the podcast.
Josh Birk:
Thanks, Mike. Glad you're back.
Mike:
It's been a while, but you've been working on stuff.
Josh Birk:
I have been working on stuff. It's been a busy little quarter. This thing called AI never really stops sleeping. I guess it's one of its benefits. But yeah, trying to catch up with all things AI, and data cloud, and especially trying where there's a wealth of stuff happening before Dreamforce, and we really would like to get our admins community armed with that information.
Mike:
You mentioned Dreamforce. Dreamforce start till October.
Josh Birk:
Well, I know, but I thought July was a really far away away, and I realized I have a trip to Montreal next week because it's June, and it's like, "Okay, right." The months, they're collapsing away.
Mike:
It literally, it's like one minute you're like, "Yay, it's February," and the next thing you know it's like 4th July.
Josh Birk:
Right. Yeah. And you have a TDX going over.
Mike:
All the hangovers. The first thing that I think we want to talk about, so what's crazy is we brought this stuff up, what are we going to talk about, and you're like, "Let's talk about the multi-tenant analogy." And I was thinking back to, whoa, that was like 2010 when I first learned about multi-tenant, and hearing the Salesforce apartment analogy.
Josh Birk:
Yeah. Yeah. It's interesting. It's actually, I think, a testament to the platform, that you can use it for years and not really understand. And I used to understand not having to comprehend exactly what's going on, because one of the, it's not really a catch 22, it's this nice cycle because it's part of the wonder of the multi-tenant structure is that you don't have to worry about it, because you log in and you're in, basically, your own space.
First of all, I think it's one of those things that does get bandied about, but sometimes it doesn't stick in people's heads. For instance, I was talking to somebody about Trailhead, and they were like, "Well, is that why we have multi-tenancy?" And I'm like, "No, no, no, no, no. Multi-tenancy was the thing, that was day one. That was the magic fuel that was moving our product before anything else was getting built on top of it."
And I think it's important to kind of have a basic understanding, because every now and then, as a developer, one of the things that people, if you come from Java, or you come from C++, and one of the things you're used to doing is whatever you want, if you want to spin up a crazy thread in an application and have it run for three days straight, the only person stopping you from doing that is you. And so then people come into Salesforce platform and they're like, "Well, Apex has these limits to it. You can't spin up too many CPU cycles, you can't do too many searches." You can't do these things. And some developers are like, "Why are you tying my hands back behind my back?" And it's like, because part of the multi-tenant architecture makes sure that Mike's org might be sitting next to my org in terms of hardware. So we're sharing a CPU.
And if Mike misbehaves too much, you might steal CPU cycles from me, and vice versa. You might slow down my application by no intent of yours. You don't even know I'm on the other side of the wall, but you're using up all of my power. And our multi-tenant architecture basically makes sure that doesn't happen. And it makes sure that you can go in and do all the things that we give you the rules to, and I can go and do all the things we get the rules to, and we're always going to be play safe with each other.
Mike:
And I remember, it's so fascinating here you describe multi-tenant that way, because I remember having to describe it as, "No, no, no, no, all of the data that we put in is in our own apartment. And all of the data that somebody other company puts in is their own apartment. And it doesn't matter what pictures we hang on our walls, they can't see our pictures and we can't see theirs."
Josh Birk:
Exactly.
Mike:
As opposed to the amount of boiling water that we have left, because we're all sharing a water boiler.
Josh Birk:
Right. Because it's summer in Chicago, and you take three showers a day sometimes. Yeah.
Mike:
Right.
Josh Birk:
Yeah, exactly.
Mike:
But I mean, perspective wise, I'm thinking through all this, and multi-tenancy, if you're going through even Salesforce admin one-on-one stuff, like this is the first day, everybody's thinking AI and agentic, and what can AI do for me. What are you doing talking multi-tenancy when we have this really cool agentic stuff that we should be talking about?
Josh Birk:
Yeah. And it's a great question, and there's a couple of answers. And the first one is to kind of go back to the analogy of an apartment complex. So that experience starts at the front door. You can't get in through the front door unless you are a tenant in the apartment building. And then the next thing you're going to do is you're going to go to your apartment, and you can't get into your apartment unless you're a tenant of that apartment.
And then start breaking all it down to the stuff that you were just saying. Your pictures are your own, the boxes you have in the attic, they're all your own. All of that is, so this is why trust is our number one value. You trust us to hold your apartment near and dear to you, and you trust us to keep that security layer, you trust us to keep the powers on. All of that is the same stuff that the agents are building on top of. That is why they're a very easy to use enterprise solution for AI, because they're like the robot butler who lives in your apartment. And all of that other stuff, the security, the power, the storage, all of that stuff, it just comes with the apartment. And your agent is able to understand where all your pictures are, and where all your boxes are, and how those boxes are structured.
And one analogy I like to give is like, well, if you're going to ask your robot butler, aka agent force, for a fork, if I'm a guest in your house, like, "Hey, Mike, can I get a fork?" You would know which drawer to tell me. You would be like, "Go to the second drawer next to the stove. That's where the forks are." How does the agent know that? And the agent knows that because of metadata. And metadata is the second tier of what makes multi-tenancy work.
One of the things back in my workshop days, a question got a lot, especially because I'm talking to old school Oracle developers and Java developers, and they're like, "Well, what's your web stack?" What they're asking is, are you running Java? Are you running Oracle? And stuff like that. I'm like, "I could answer this for you, but it's not going to be the answer you think it is, because our data structure doesn't start like a normal database does. Our database structure starts with multi-tenancy with a metadata tier on top of it." And what that metadata allows you to do is you can put your forks in a drawer, I can put my forks in a different drawer, and metadata can tell the agent, "This is where those forks are held."
And let's say you ripped your kitchen apart. Now, if you're going to rip your kitchen apart and put your kitchen back together again, you're going to get a contractor. You're not just going to go pay a couple of teenagers with some sledgehammers and just knock everything down. I mean, it might start that way, it could be entertaining.
Mike:
I mean, if you watch HGTV, that's how it's supposed to go.
Josh Birk:
It does kind of start that way, right. But at some point, you're going to want to have a plan for how tall the counters are, where the counters are going to stop, all of this kind of stuff. You're going to have a blueprint. And a blueprint is going to instruct everything down to where your drawers are. And that blueprint is crafted for you in metadata whenever you're doing things like creating custom objects, and you're creating custom fields. And everything on the platform basically has this blueprint to it. Now, the great thing about that blueprint is if you invite me over to your apartment and I'm like, "Dude, this is a killer kitchen. I would love to have this kitchen in my apartment," you're like, "Dude, I'll just get you the blueprint." And then we just package up that blueprint, I take it over my apartment, and then I can just build out the kitchen exactly to your scale.
Mike:
So, I'm thinking through all of the times that I've built and remodeled my kitchen, as admins do, continuing the metaphor, and failed to write blueprints. So now I'm building an agent and I'm telling it forks are in the second drawer from the left of the stove. And that's the instruction I give it, but it has to go learn what the second drawer is because it doesn't have a blueprint to look at.
Josh Birk:
Yeah. So this is a very strange little section of metadata and AI. It was one of the first things that I heard during a workshop, and it's always stuck with me. So you've got your blueprint. Your blueprint knows the size and scale of your kitchen, it knows how many drawers you are, and it knows where the drawers are. Now, let's say you want to identify which drawer is going to be the silverware drawer. When you're building out the custom object and you're building out the custom fields, we know that it's good to have a description fields.
So if there's any ambiguity, because sometimes you might have a similarly named field, you might have a similarly named object, something like that, and you want to make sure people are guided to the right drawer, so find that fork, well, if it's a good idea for a human, it's a great idea for an agent, because when you say, "Get me the largest fork in the drawer," it's going to go through what it knows about the data model. And if it sees the word fork in a description, it knows it's going in the right direction. You're giving it that breadcrumbs.
And this is why it's like, "Which descriptions fields do you mean, Josh?" And it's all of them. It's the ones in the custom actions, and we won't even get into instructions yet. It's all the ones in your custom fields, it's all the ones in your custom objects, et cetera, et cetera, et cetera. You want to leave that little breadcrumb trail so that when agent force is doing its little agentic reasoning, and it's like, "Which custom action should I use? Which standard action should I use?" You're going to end up with a much higher rate of success.
Mike:
So what I'm hearing is the importance of metadata in terms of describing things, in any possible term that a user could use to give that to an agent, so that an agent doesn't have to reason, "Oh, date on opportunity means contract date, as opposed to close date, because you have six date fields and you title them date one, date two, date three."
Josh Birk:
Exactly.
Mike:
And the user, because it's nomenclature within the organization, oh, well, the second date is the date it leaves the warehouse, and the third date is the date it's expected to be delivered. But if you ask an agent that it's not going to know that until you tell it through metadata.
Josh Birk:
Until you tell it through metadata. At best, if it doesn't know, it will guess, which is problematic for two reasons. One, obviously it might be wrong, but it also might be right two times out of three, but then you don't know that third time. It makes your testing even harder anytime that the agent has to guess for it.
Now, people might be listening to this like, "Well, okay, I understand that, but how powerful can a description field be?" And it's true. It's only so powerful, but the great thing is, this is why, and it's one of the things I think people, I really like talking about this, because one of the things is I think it demystifies agents a certain extent. We treat agents almost like, I just referred to it as a robot butler. So we're already into a sci-fi. We've gone from an apartment complex to Star Wars, right?
Mike:
I'm thinking Rosey from the Jetsons.
Josh Birk:
Yes, yes. I love it. I love it. But there's so much human in the loop that's involved. And we have to remember when we talk about guardrails, all agents have guardrails. It's the thing that keeps them from saying horrible things and doing horrible things. And there's so much we can control over an agent just by text, just by writing to it. And so we've been playing with agent force internally. And one of the first things I had to do, because I was trying to make sure that our users could talk to it like they would want to talk to it, right? So when you say my blog post, you mean a blog post that our wonderful Eliza Riley created an object record for, and then added you as an author, and then added Kate as a reviewer. So we're really talking about contributors.
But if you say the word my without giving any context to the agent, it's going to think you mean the current owner. But instructions, you can say, "Hey, in this topic, when I say my, when I say blog, I mean these different things." And so that's the first place that the breadcrumb trail is going to start going, and it can be one of the little behavioral issues. It's not responding in the right way, or it's not using the right style and things like that. The prompt builder instructions can solve so much just by writing a few sentences.
Mike:
So, I'm thinking through the apartment analogy. And I've used Rosey before, because I do think eventually at some point we'll have, I would like to have a robot in my house. Amazon had that little puppy dog thing.
Josh Birk:
Yeah.
Mike:
I should have signed up for that. But in hindsight, I don't think AI was really where it should be.
Josh Birk:
It was basically an Alexa on wheels, I think.
Mike:
I know. I was afraid it was going to go downstairs and there goes $2,000. What was that, literally here's the sound, it was like, "Zoop, zoop, pom, pom, pom, pom, pom, pom."And then mom would be like, "What was that?" And I'd be like, "That's the sound of $2,000 falling downstairs."
Josh Birk:
Not being able to use stairs.
Mike:
You can't use stairs. But I would like to have that. So, I'm thinking through the apartment analogy. And basically what you're saying is, so Salesforce can roll out the ability to find forks, to all of its agents. And so everybody in the apartment complex benefits, but what's key is your blueprint, because where you keep your forks is different than where your neighbor in 5B keeps their forks. And so if you are filling in your metadata and Salesforce ups the ability for agents to do things like find forks, like, "Oh, now they have the ability to find spoons," everybody can benefit all from one action. But just because of that action doesn't mean that your agent is up and running because it needs the metadata to really target in on what does this action actually mean for me and the customization I've done.
Josh Birk:
Right.
Mike:
Is that fair?
Josh Birk:
That's fair. And remember, your Rosey and my Rosey, they're the same model. And if there's upgrades, you're going to get your Rosey upgraded, I'm going to get my Rosey upgraded.
Mike:
Kind of like our phones.
Josh Birk:
Like our phones, right? Every now and then, it's like, "Oh, yep, you're three updates behind. Please restart your phone."
Mike:
Any more it seems that way, doesn't it?
Josh Birk:
It really does. They're coming faster.
Mike:
I never used to fall behind. The other day I was like, "Oh, you're three updates behind," it was something like that. I was like, "How?"
Josh Birk:
"I thought you were doing this for me." But even if I copied your kitchen one to one, but we also then give me the ability to swap out the drawer that forks are going to be in, or to add a new cabinet and things like that. And the great thing is about metadata is my Rosey instantly knows my new kitchen layout because of the metadata.
Now, going back to the blueprint and the description fields and the topics, and also the other thing to mention here is the quality of your data. How well-structured is your kitchen when it comes to, do you have all the forks in one drawer, and the spoons in another drawer? Do you have one of those nice slotted trays?
Mike:
What do you do if you have a junk drawer?
Josh Birk:
What do you do if you have a junk drawer? And it's like, what if you have everything in the junk drawer? Well, Rosey's going to have a really hard time finding your fork if everything's in the junk drawer. So, all of these things we're talking about, metadata, description fields, quality of instructions, guard rails, we also have to all go all the way back to the OG. Quality of your data structure, right? It's great to have a description field to help them guide, but it's also a really good idea. Do you need three fields that end with one, two, three, and four? Or is it now the time to convert that into a pick list value, which might be easier for Rosey to work with?
Mike:
Yeah. I'm just thinking through that, because I was also thinking of how many I got stuck on junk drawers.
Josh Birk:
We're Midwesterners. Is it a Midwestern thing?
Mike:
You ever ask a question and then somebody totally answers, and you're like, "Sorry, I wasn't listening. I was thinking of a junk drawer."
Josh Birk:
Well, see, and that's now I have to fall back on my old, "Do we have to explain what a junk drawer is? Do people know what a junk drawer is?"
Mike:
I mean, it's like everything that doesn't make sense. My junk drawer is the water filter for my fridge, my owner's manuals, a pile. And I mean a pile of pens and pencils from various local establishments. And they're in varying states of operability. So, that's why you have three, or I got at least 10. 10 pens. Probably three of them work. And the other seven are just there, it's like a lottery. If you get it and you go to try and write something, and that's how it gets thrown away. And then straws. Straws, and then packets, ketchup packets.
Josh Birk:
Ketchup packets.
Mike:
Hot sauce packets.
Josh Birk:
Hot sauce packets, hot mustard packets, anything from a Chinese store.
Mike:
Right. And then here's where you throw in, it's a real wild card, this is where the podcast goes completely off the rails. You throw in the occasional thumb tack rubber band.
Josh Birk:
Just put traps in for yourself.
Mike:
And the newest thing now is those 3M wall sticky hanger things.
Josh Birk:
Oh, yeah. Those have escaped.
Mike:
That's a junk drawer in the Midwest. Oh, and a flashlight. Got to have a flashlight.
Josh Birk:
A flashlight. And a flashlight.
Mike:
Flashlight that may or may not work and may or may not have batteries in it. Does it matter? Still in there.
Josh Birk:
Still in there. Still in there. Yeah, that's about it.
Mike:
But no, so back to the regular scheduled podcast, already in session, I was thinking through the junk drawer of like, the junk drawer to me in any database, or mostly in all of the Salesforce databases I've managed was the description field. People throw everything in the description field. And then I can foresee now, God, the nightmare of, "Well, I asked Agent Force, what was the last five calls that I made, and it couldn't find it." "Right. Well, did you log those as activities?" "No, I just added it as bullet points in my description."
Josh Birk:
Exactly. Yeah, and it's like, we're humans. And the amount of interesting human behavior I've seen over the years of how people have implemented Salesforce. But there's kind of the old adage, if it ain't broke, don't fix it. And if I'm doing this day in and day out and it's working for me, great. But the times they are changing. And this is back when we were trying to get people to move from visual force to web components, now aura. I'm like, "Don't fear it. I'm not asking you to go and delete all of your existing components and start from scratch and build everything up with all of these amazing demos that I'm talking about, but now is the time to start getting your feet wet. Now is the time to start looking ahead. Now is the time to go to Trailhead and tinker with your first agent." "And now is the time to start asking really hard questions like, how messy is our data structure? And what have people started?"
So, I'll go way off on a tangent, but I swear I'm getting somewhere. Back when I worked for a major retailer as their lead client side developer, we had a problem with pop-up windows. And the problem was, because everybody knows-
Mike:
Got pop-ups for a long time, were just the bane of everybody's existence.
Josh Birk:
Right, and they get hidden behind other browsers, they just do all this behavior you don't expect.
Mike:
Pop-unders. There was pop-unders too.
Josh Birk:
Yeah. So me and my old friend and colleague, Jamie Dehansen, he was the designer. And so we started a project to take that down and turn it into a modal window that would be on the page itself, that Jamie and I could control 100%. The event structure, everything clicks. We launched that thing, we're so proud of ourselves. This thing is cool, it looks great, it works wonderful. And then the complaints. Started swarming in. I don't mean two, I mean like 20, I mean like 30, just over and over again. Because people kept asking, "Why did you take your comparison feature away?" And Jamie and I are like, "What comparison feature? We don't have a comparison feature." And then we realized that people were going to a product item, clicking the pop-up, going to another product item, clicking the pop-up, taking the two pop-ups, putting them next to each other.
They had built their own feature without even asking us. And so we fixed it by adding that functionality in, like the way we wanted it to work, and everybody was really, really happy. But that's the kind of thing that happens within a Salesforce org. You didn't think that you gave them the feature of transcribing their phone calls into the long text field that was meant for something else, but you did, and they're using it. And that's the kind of, I think you're credited for saying the walk around the broom style of admin.
Mike:
Sabla.
Josh Birk:
Sabla. You need to look over somebody's shoulder and be like, "That's not how I meant you." We need to fix that description, that long text field, and I need to make it work in our data structure so that Rosey can find those calls for you.
Mike:
So, here's a fun fact, and this is a deep cut for people that listen. So, I came up with Sabla after watching planes, trains, and automobiles.
Josh Birk:
Oh, really?
Mike:
Yeah. Let me tell you how. How does planes, trains and automobiles open? Opens with an ad agency in downtown Chicago. I think, right?
Josh Birk:
It's New York.
Mike:
It's New York, okay. New York. The CEO is looking at what would be a billboard, except he's sitting at a chair in a well-lit office room. My friend and I were watching this, because we watch planes, trains, and automobiles every Thanksgiving. And he owns an ad agency, and he just dies laughing every time he sees that, he goes, "So what's funny about this is how executives look at billboards, but everyone else is going to look at this billboard going 60 miles an hour down an interstate trying to make a corner and avoid a semi." He said, "Because nobody looks at billboards from the perspective of the person they want to sell to."
And I was like, "Oh, it just dawned on me," because I had just done a Salesforce deployment. I was like, "I didn't look at that page that I deployed. I looked at it from my desk with my headphones on, uninterrupted, knowing what I was looking for, not on a phone call with an irate customer because their plant had just died or something, and trying to work through how do I disseminate this information." So there you go. There's the history of Sabla.
Josh Birk:
Love it. Love it. Yeah, the interview I did with Katie Coats, she was like, "Don't tell me how you've used this application. Just show it to me."
Mike:
Right. Yeah, yeah. Okay. So put a lid on this.
Josh Birk:
Yeah.
Mike:
All the admins out there are sitting like, "I was supposed to deploy Agent Force three weeks ago," or, "We're still trying to figure out how we're going to Agent Force, but my CEO wants it deployed by Dream Force."
Josh Birk:
Yeah.
Mike:
What should I be doing now? Because it feels like I should be learning to build agents, and you should.
Josh Birk:
You should. But, we go to these workshops and we're like, "You're already an AI builder. You're already an agent builder." And the reason I can say that confidently, and this is why we're talking about things as basic as your data structure in your description fields, remember your training, all of these things that you already do when it comes to who can come into the apartment? Who's allowed in the apartment during certain hours? Who can go to the certain rooms? Who can use the certain? All of these things is the stuff that the agent is going to build up on. So the better you're already doing your job, the better the agent's already going to be. You're already putting in the hard work, that's the hard work. Building the agent's easier. Way easier. Like Jen and I have compared notes, and most of the flows we work with agents are fairly intermediate in complexity at bust. I've got a few that are five or six steps at all.
So, if you don't even have to be Jen League, Queen of Flow, you don't have to be a crazy flow-natic. You just need to know how to build flow. Now, you know how to build flow, great: you know how to build custom actions. And when you take that flow and you convert it over to a custom action, all of that work that you've put into the apartment leading up to that moment is going to make that agent so much more successful. So it's like, don't think of it as this brand new thing that's off on its own little lonely island, it's more similar to when we released Flow, or when we released things that are new, but they're new on top of the platform. And so all of the things you already know how to do on the platform, all of those things are going to be important.
In one of the blog posts we have coming out, one of the things Jen reminded me to put in there is, "Remember to think of your agent like a user. It's a Rosey. It's another thing in your apartment running around doing stuff." And so all of your ability to be like, "Oh, what fields should I have access to? What permission sets should I give it?" All of that, it's all stuff that's going to make your agent more successful.
Mike:
That makes sense. I mean, it's also like cleaning up before you get new furniture.
Josh Birk:
Right. Exactly. Or maybe throwing out that old sofa.
Mike:
Yeah. I live in a college town, that happens every May. Every May, at the end of May, you drive around, and people can go sofa shopping because all of the college kids are moving out, and all of the target futons, and IKEA futons are at the corner. And you realize how hard college kids are on furniture.
Josh Birk:
They're very hard on furniture, and they usually get it secondhand in the first place.
Mike:
Right. They got it last year off a street corner.
Josh Birk:
Exactly. And became anew.
Mike:
Awesome. Josh, thanks for coming on and helping us understand our apartments, and understand that we should be blueprinting them. But more importantly, I mean, the cleanup of data doesn't just stop there, it's also the cleanup of metadata too.
Josh Birk:
Yeah. Like I said, remember your training, and I shall be successful. Thanks for having me, man. This was a lot of fun.
Mike:
So that's a wrap with this chat of Josh Birk. Huge thanks for coming and unpacking the foundation of Agent Success. I can't tell you how important metadata is, so be sure to check out his blog post that he's got coming up. And remember, your data structure and metadata aren't just back end details, they're the keys to unlocking smarter, more helpful agents. Whether you're prepping for Dream Force, or just organizing your org, start with a blueprint. Now, if you found this episode helpful, do me a favor, share it with some of your friends. And be sure to hit that subscribe button for new episodes downloaded. And with that, until next time, we'll see you in the cloud.
Hosts & Guests
No transcript available for this episode.
