Name: A Salesforce Developer’s Guide to Headless 360
Uploaded: 2026-08-11T16:30:15.426Z
Duration: 1 h 1 min 24 s
Description: A Salesforce Developer’s Guide to Headless 360

Transcript for "A Salesforce Developer’s Guide to Headless 360": Good day, everybody. Welcome. Welcome. Welcome. I'll give you a few seconds for everybody to to jump in and join. We've got a great session ahead today talking about Headless three sixty. Just as you join, I'm curious. I'm always sort of curious. If you see the chat bar in your window, if you want to jump in there and just post where you're joining from today. I'll just post, there we go, joining from Australia. I'm curious, there we go, Indianapolis, US. Oh my goodness, we're coming in. Oh, okay. We got a lot of people on the call already. Look at that. That's perfect. That's exactly what I was looking for. Wanted to just check-in and see exactly where everybody's joining from around the world. And while you are in the chat, you should also notice in that side panel as well, there's a Q and A section. Throughout the session, if you've got any questions that you'd like the team to jump in and address directly live on the session, don't pop it in the chat. Make sure you jump over to the Q and A section. In the Q and A section, you'll be able to see any other questions that other people have asked as well. If you see any in there that basically is exactly what you were about to ask, make sure you give that particular question a thumbs up so that we can see the most common questions that most people want to hear about. If we are pressed for time, we can prioritize the ones that have the most backing behind it, so to speak. Vote for the most popular questions, if that makes sense. Fantastic. Alright. Look, I might actually just jump straight into it because I can see a flurry of excited messages from around the world. Always good to see. So again, welcome to today's webinar is a Salesforce Developer's Guide to Headless three sixty with Salesforce. This is us, this is Salesforce Ben. So if you're not familiar with what we do, we do all sorts of things in the Salesforce industry across the world. We've got, of course, our articles, our written content. This is is tutorials and news and all sorts of different bits and pieces you can read about on our site. There's the newsletter for if you'd like to subscribe and stay up to date with all the latest that happens in the Salesforce world. We're sort of making sure that we're keeping our newsletter subscribers up to date. There's our events as well. There's these digital events like this, the webinars. We've also got our in person events as well for things like TDX and of course upcoming soon is Streamforce. There's also a YouTube channel. So if you like if you're like me and you sort of like that more, visual, videos, you prefer to sort of learn learn that way or see things in play as a video instead or as well, We've got the YouTube channel and of course, we have our SF Ben Insider podcast as well. Alright, but again, as I always say, it's enough for me, so I'm going to welcome our fantastic team from Salesforce to the stage. We've got David Beloz, who's the field CTO and distinguished architect from Salesforce. Philippe Ozil, who's the principal developer advocate, and Sedanar Nandakumar, who is the director of technical product marketing at Salesforce. Team, if you could, join me on stage, I'm sure our audience would, love to to meet you all. Thank you very much. First first and foremost, thank you very much for coming on, and joining us and and running this session. I know, we've had a lot of interest in this. It's going to be really good to see what you guys have to say. Without further ado, this is our agenda today. We're going to start by talking about the headless shift for Salesforce Teams, jumping into coding agents meet Salesforce. We're going to see a live demo. We're going to jump into Agent for Skills, Governance, and Trust, and then finally, our live Q and A. Just a reminder with the live Q and A, we've got two bars that you can communicate with the team in. There's the chat, we'd love to see their comments come through as the session goes on. But if you do have a question that you'd like answered in that Q and A, make sure you jump over to the Q and A tab. Look, without further ado, I'm going to hand it over to the team. We're going to go first to Section one, which is the Headless Shift for Salesforce Teams. Perfect. Hey, everyone. David Belisle's again. We're gonna dive into a few topics today. Hopefully, they're gonna be fun. And to get things started, let's go ahead and take our first poll. We want to go ahead and get a feel for where you guys are coming from, what your current understanding is. So if you could go ahead and fill out the poll, what's your understanding of headless? It's a very weighted question depending upon if if you come from a developer background or not. Interesting. Interesting. Yeah. So nice little nice little spread here. Give it a couple more seconds. Alright. Good. Good. So that gives us a a good feel for where you're coming from and, and how we can shape the conversation. Hopefully, it's gonna be a fun one. So when we're when we're thinking about what headless means, if you come from a developer background, you sometimes hear this referred to as the little h. From a Salesforce perspective, you sometimes see this with a a big h and a three sixty behind it. So, let's start with some of the basics. You know, when we when we think about Salesforce, we think about vibe coding, we think about all the tools and agents that are now available, and then we we mass that altogether. Right? What happens when these things meet Salesforce? So the power of the skills, the power of the tools themselves, governance and trust considerations, all of this sort of stuff plus the dev life cycle. There's a lot to cover. So, I just wanna kick things off with some of the basics. You know, I've I've had this conversation a gazillion times lately, especially since we launched this. And, you know, for some people, it lands completely different every time. So, we're focusing on developers in this session, but what do you think the headless shift and specifically headless three sixty means for those developers in that audience? Oh, great question. Thanks, David. So, I'm sort of gonna piggyback on what you just said there. You said white coding. That is sort of like the industry term right now. Everybody can build stuff pretty quickly. So it's it's a matter of, moving, the responsibility from building something quickly to actually what that necessarily means. Right? So if the job of a developer is moving from becoming just, you know, building to, if that is going to get automated, then the job becomes superficial. That's basically the shift that we're talking about. Headless isn't about just adding an API that we can bolt on on top of the platform. It's about opening the business logic that you already have on the platform. So that's about twenty five plus years of business logic, of your business processes that your organization sort of owns, and you're now able to open that up and make it possible for agent decoding tools to use and accelerate productivity for the developers. Why that's possible? The reason comes down to how we have framed the platform to help. We have about 60 plus MCP tools that we've released. We have about 90 plus skills across the entire Salesforce ecosystem, CLI commands that provide access to the entire platform. And that also sort of shifts the surfaces where people work. So it's no longer just, like, people on lighting experience, configuring things, or building stuff. It's now any coding tool of your choice. So that's sort of, like, changes the developer persona from where they work and the type of work they also do to kind of, like, build these applications. That makes sense. Couple of things that you hit on there that I I think is interesting. I think one of the things the tooling is doing is it's it's really shifting the decision of, you know, not necessarily where the logic lives, you know, but, you know, how do the tools meet that logic. Right? So some people are sort of developing all that logic in these new Vibe tools, and some people are realizing, hey. We've already built all of this stuff, and, really, the value is lying in the acceleration the tool provides. You know, one thing interesting too is when you start thinking about what happens after that first version or after that first prototype, you start to peel the onion back and you get into things like validation rules. You get the sharing model. You get approval processes for how things work work through the development life cycle. And and I think a lot of that stuff doesn't need to be reinvented. You know, if you think about this, you know, a lot of people that have Salesforce orgs have sort of accumulated a whole bunch of work across a ton of years. Right? And some people view that sort of as a messy org. Maybe we need to start fresh, start all over. But, really, I think with the with the advent of headless, that's that's actually some of the best orgs. You've got a bunch of work. You've got a bunch of labor. You got a bunch of great stuff that's built. And I think now when you add the tooling to it of headless, we can really accelerate that. So I I'd I'd summarize my sort of view that, you know, the word headless, I think, throws a a few people. They think that headless means that the UI goes away, and I think it's actually the opposite. I think it just means that, you know, the logic that you built actually just shows up wherever the user wants to exist. So it's not that there's not a UI. It's really that we're shifting it to a different surface. So, so I wanna keep this, sort of going. Philippe, you know, one of the things I run to with my customers, the architects sort of understand it immediately. Right? It's like, we've been doing headless for years. Why is this so different? Right? And delivery teams and people that are doing implementations and other stuff sorta take a little while to to understand what headless really means. Right? So you're closer to developers. What are you hearing, from those individuals that have actually tried headless, done headless, and what do you sort of see they're experiencing? I think you made a super important point. Headless doesn't mean without UI. It means with many UIs, in fact. So you have multiple surfaces that you need to cover. But before we talk about getting to the UI layer, you first need to build things. And with headless, there are new ways of building. I would say you're increasingly able to go outside of a pretty fine toolkit or or set of tools, you can use different things. And as I'm working with developers, I've seen different paths for adoption of these tools. And agenting development is clearly one of the tools people have been struggling with, to be honest. It's a bit of a a wild west there because there are different approaches. And what I've seen in terms of, like, struggles is that I see a lot of people, experimenting with agents and coding. So I saw a lot of overprompting, people trying things, doing small iterations, not thinking about the big picture, not thinking about using plans, working with our skills and rules. And in fact, the the adoption and the release of of Salesforce provided skills and rules are are a good thing because we need a bit of of standard, tools, and this is a way to provide standard tools without locking people in specific, IDEs. So that's, for me, one of the biggest trends, like, the adoption of skills and MCP, that is gonna be a game changer. Also, when people start adopting, coding agents for development, what they tend to do is is use agents generate a lot of code. They also generate a lot of tests, but they're they're never really looking at what is being tested or what is being delivered. It's like velocity comes at a cost and often quality drops. So I would say it's probably the right time to reinvest and make sure we have solid DevOps practices, make sure we have really robust continuous integration, continuous delivery chains. This is really not new. This is not something that really changed with headless, but I think it's becoming even more important now in this headless ecosystem, really. And finally, I would say, yeah, just continue to embrace this this new technology, but also pay attention to what we're building. In the past, every single agent, every single developer had to bring up their own tools, and now we're starting to release, standardized tools. One of these recent releases that we just shared, I think it was yesterday, is the launch of plugins. So these plugins allow us to bundle rules and MCP tools pre installed for agents. And there's a really great one in the Salesforce skills repository that you can try for Cloud Code. So I would really suggest people try take a look at this. That's the future already. Very cool. That's it. one interesting one interesting thing that you, you sort of touched on and and said that I wanna get your thoughts from our product. But, one thing I found interesting, I've had, you know, talked to a lot of customers, a lot of developers. and architects, and I find it interesting that so many people record every single meeting that they're in. Right? They'll have developer meetings, product meetings, you know, what do you guys need, what feature does what, and nobody takes those recordings. Nobody takes those transcripts and translates them into test cases. Let's validate what the business actually wants and then use those test cases to actually drive the development and what the agents are doing. So it's a bit of an interesting trend that I'm seeing of take the recordings, generate test cases so you know that that's what they said, and then reverse engineer that into agents. But you're a lot closer to product, especially at Salesforce. What thoughts do you have, sort of on on what you're seeing from the product side? Yeah. Yeah. So I think that is a great, sort of segue into talking about how, like, spec based development is sort of becoming the new paradigm going forward. With white coding, there's, like, immense power. You can tell it to build something and it'll build, but it needs to know what to build. And to your point, giving it the right context means that it's gonna create exactly what you want, and that context is sort of buried in conversations in, to your point, meeting recordings, in probably one of Slack conversations, in Canvas', in Google drives. You know? The the biggest power with Headless is that we are now able to have access to all of that data in one place, bring it all together, and create a master spec that can then drive into building these amazing features. And that is what is sort of like, what enterprises are trying to do and that's what Salesforce has been doing internally as well. The fact that we are sort of like trying to understand where, you know, the the need is, what sort of, you know, conversations have happened in the past around some of these things, and trying to bring them all in into an active part of the product development life cycle. That sort of changes the way from, you know, having one person script out a set of business requirements and the developer goes on and builds it. That sort of, like, changes the way things have been operating. Makes sense. So, one thing that that brings to mind for me at least, you know, just for my own orgs, the orgs that I build against, you know, the the customer orgs that I I talk to, they sort of have this view. You know, I'm not exactly sure what all is in this org. I mean, this thing's been alive for seven years, twelve years, whatever it's been. There's, you know, who knows how much Apex code? Was it good code, bad code? How many workflows? We've got 600 workflows, whatever. Right? Is is headless something that when you start viewing it from a developer's perspective, you know, are the agents gonna discover what's in all these orgs so that they don't butcher, you know, what's going on? Like, how are they viewing? Do we need to start over with a new org? Like, you know, how much of that what are you seeing just from a org cleanliness, or do you see it more that you can just start with the tooling, the orgs that you have, and we'll, we'll work around it? So yeah. Go ahead, Felipe. No. I was gonna say we we have great tools for this, and I think the API catalog and the brand new headless three sixty MCP server are already here to support you. Because in the past, like you mentioned, there was no notion of architecture. There was no notion of reuse. And with these tools and the exploration of the already dense metadata that is already in your org, you can now reuse and, follow, I would say, consistent patterns. You wouldn't create, like, a one off each time you run a prompt. So maybe you had something to No. That was spot on. I was just gonna, like, piggyback on that. add. Yes. To to, David's point, some of these existing orgs have a lot of business context, and the coding tools that we have, and the MCP tools that have, you know, that go along with it helps us understand the current state of the art. And that is, like, gold given that there there could be, like, multiple years of work that has gone into some of the business logic, you know, across the board. Even understanding the state of where things are, that's gonna be easier for somebody to kick start and, figure out what the future direction should look like. And, you know, doing that manually over doing that with agentic coding tools and the help that you can get based on that is, like, a massive head start into building something afresh. Makes sense. So one area as we sort of, continue on talking and and transitioning into, you know, looking at how the coding agents themselves meet Salesforce in our next topic here. One of the things that that I'm seeing is the admins are sort of becoming builders. Right? And so it's kind of this thing of where is that line. Right? In my orgs and others that I'm seeing, these admins are saying, tell me if my org has these features turned on. Go ahead and tell me how I would construct, you know, this thing in my org. Right? So So it's sort of this blend between when we talk about coding agents and Salesforce, we're sort of starting to include the admin in some of that. Right? And depending on the size of your organization, the admin may be the entire developer pool. Right? For others, lines are clearly delineated. But when we talk about coding meets Salesforce, one of the things we wanna get a a feel for from the audience here is sort of how are you, whether you're an actual developer, full blown developer, pro code, or whether you're an admin, gotta pull it together. How often do you use coding agents with MCPs and with coding skills? Curious what you guys are doing now. Alright. Just exploring. Interesting. A little bit of daily. Yeah. Alright. That's a it's definitely a good skills every day. MCP never. So one of the things that that I think as we as we transition and talk about this, you know, as I alluded to, I've seen people that are using these these tools and using the Salesforce MCPs and skills to really better understand what's been built in their org, what lives where, how can they start to tap into this. Right? Especially when it comes to things like, let me build something in a vibe coding tool that does x y zed. The only problem is we've already built some of those things in the org. So now if I'm rebuilding it, I've got two potentially parallel and conflicting components here. And so when you think about, you know, how these tools are gonna be used when you dive into this, maybe it's your first time, maybe you're starting to use that a little bit more, Philippe. Go ahead and and let me know sort of where do you see the devs, making the biggest mistakes. Right? I mean, the obvious one would be I sit here and I churn for six hours trying to figure something out. The agents just go into town. I just burn a million tokens in a day trying to figure it out. But from your perspective, you know, what are you seeing the more expensive mistakes being when people start experimenting with coding agents, whether you be admin or full developer? Yeah. I I think I'm gonna probably repeat a bit what I said, earlier, but I think the the lack of skills or guidance is probably the biggest, factor of, I would say wasted tokens, wasted resources, wasted time. If you don't have clear, guidelines, if you don't have a formalized specifications, you're probably gonna do a lot of iterations and not get to your results really. If you're not clear about your intent, if you're not backing your your plan with solid grounding, that is not going to work for sure. And so this is really why we need those tools there. And they to open up a bit, these are not really limited to developers anymore. We have recently announced that we're gonna release also, headless capabilities for agent force for setup. So soon you'll have also administrators who will be able to discover and and basically administrate their org from within an agent. So it won't be technically a codec agent, it will be just an agent. They will have access to more and more features. So now it's very limited. We have maybe the ability to control permission sets, but this is gonna expand. And the whole concept is at some point you can basically develop and administrate your org from anywhere. That's really pure headless. That's what we're going to see in the future. It will probably take a couple of iterations but we're getting there. Sounds good. So some good tactical ones there. Expensive mistakes, I think, are are tend to be more architectural. There's a few that that I know I'm seeing. The first with when you look at the MCPs and and the power that they're bringing to the table, right, the the concept here being that API is very declarative. Right? And so it's very clear what they can and can't do. When you start adding agents to it, the whole point of an agent versus automation is that it needs to reason. It's it's looking at how can I reasonably pull this thing off? Right? An API just point blank says if this, then that, and and automation can do that. Right? So when we start looking at at agents, especially coding agents, you know, a few things that I'm seeing. One is that we sort of point it at a Salesforce problem, and it rewrites some of that logic. So what I alluded to earlier, right, it'll it'll write a validation rule. You know? It will the demo looks great. It all works flawlessly. You know? And then, you know, fast forward, somebody changes one of those rules in Salesforce where it belonged because flows and everything else were using it. And now you have this conflict between this little validation rule that you built and the validation rule that was sitting in New York. Right? So, that's one of the things I'm seeing too. I think another is when business rules, end up in the prompt instead of in an action. Right? So we're we're feeding the prompt, and we're saying these are the the rules that I want you to do for me. Right? And so it's kinda like business logic sitting in a UI right back in the days. We'd write UI logic. It was really business rules. And when it's tightly coupled like that, we really start to see issues. So, I think, you know, one is putting business logic in prompts, number two. I think, two, people are are building agents for something that flows and automation was meant to do. One of the things I I do with customers, I I and this happens internally as well, but it's it's also with customers that somebody will say, I've got this great idea for an MCP. I've got this great idea for an agent, and they start talking about it. And that use case is not AgenTek. That use case is automation. Right? And so I think we have to sort of have a bar where we ask ourselves first and foremost, is does this already exist? Is the validation rules and the business logic already there? If so, don't reinvent it. Don't put it in a prompt. Second is if I'm gonna create something, can that be satisfied with automation? Can that be satisfied with an API? Right? And then when we sort of say no to all those things and we start looking at reasoning, right, at that point, I think that it makes sense to introduce agents and and let the coding agents start start cranking that out. One of the things that you'll see too is is as you do that, you'll start to see that it's added latency to a lot of this. Right? So the the thing would actually be faster if you leveraged workflows and automation, but But now you've got an agent and an MCP doing it. You've got a whole bunch of buffer in between that. It actually becomes slower. Right? So that's that's a few things that I'm also seeing as well now. Philippe, couple of things as we sort of move this forward. Right? You know, a a pattern that I noticed is the teams are are doing well. There's not much that's boring about it. Right? There's not a whole lot that's entirely too clever about it. But when you see devs getting ready to do builds. Right? So I just cranked out this thing and it's glorious, and it starts cranking. Right? And then it expands a little bit, gets a little more complex, gets a little bigger. We got multiple people all trying to collaborate and code against it. Now you start hitting this. You know? It runs on on my agent, you know, and we actually need to have a dev build. Now we have to do software development life cycle. We actually have to move these builds, test the builds, version the. builds, you know, all of that stuff. So what are you sort of saying that the devs are doing when they approach builds that works and and the things that don't? That's a very good point because I think we're currently missing the DevOps and governance part. Because all of these tools are so new, individual developers have their own configuration. Not a lot is being shared and not a lot of effort is being put I would say in the general governance like when you're working with multiple teams like we're reinventing, concepts that already exist. But obviously, we have to adjust them a bit to the new way of developing, the agentic development. So I think that's a whole sphere that we need to really invest in. Of course, you you still need again your your really strong CI processes, your own DevOps processes, but you need also to reinforce and to take in account all the, headless development you add on top of it because it's a really different angle, I think. That's for me. It's a key point where we need to invest both as a company and also as customers individually, in their own companies. That makes sense. Now we've we've sort of touched on, you know, the developer proper, coding tools, things like that. We alluded to that the admin is becoming more and more of a builder, whether they're. building configuration or building flows, or whether they're actually building apps. You know, we've done a lot that's developer facing, but I see a lot of especially execs, a lot of people in leadership that are trying to figure out this balance between quickly accelerating with all these tools, and let's make sure that we govern. Let's make sure that we're actually doing it. What what we haven't talked about yet is, sort of a a pillar that relates to things like HXL, which is what is the what does this even mean to somebody who's a consumer or an end user of any one of these things? Right? So if I'm an end user of Salesforce, if I'm an end user of an app that you built that's powered by Salesforce, if I'm just that end user, what does it mean for me? Is headless something that I don't have to worry about and it just doesn't affect me, or does that give me, an advantage? I don't know. Wondering what you think. Sure. So headless doesn't mean that we do not have an interface. It just means that we're gonna meet people where they are. Meaning a consumer of Salesforce no longer has to remain within the lighting experience. They can use the surfaces that they use every day. It could be Slack. It could be Teams. It could be any, you know, sort of, like, user interface that they are gonna be doing their work actively on. They're able to bring the Salesforce workflow to that channel. That is what Salesforce that's what Headless sort of, like, opens up. Right? The possibilities to kind of make it available as a multi surface, working paradigm, which is so much different than how, you know, traditional Salesforce users have been, like, using Salesforce for a very, very long time. I think that is, like, the fundamental shift. And what that also means is we are improving the agent experience for the future. Because what we are dealing with here is, yes, we ask a question. Yes. The agent responds back with something, but but it cannot be a full block of text. Right? Your point, the agent is supposed to have, like, a reason for why it's implemented in the first place. It needs to be an you know, something more than automation, something that involves reasoning. But then it also has to be built in such a way that there are actions, like, right there in flow that allow them to kind of, like, interact with and move forward. That is what HXL sort of, like, makes makes possible. Right? So with headless experience layer, we are sort of able to remove that block of text that otherwise would just, like, sit on the user interface waiting for them to, like, read and react to to something that's interactive right at the surface that they're using this on. Could be their mobile, could be their, you know, Slack, Slack board. It could be that they're gonna be using this on Teams. It's all available for them to interact right there. That is what we are sort of, like, providing as a part of, like, the shift. And you'll see a lot of this as a part of the demo later on as well, but that is what, you know, where we see the future of agent experiences are gonna go in, in in in a few years. Sounds cool. So, you know, we we can wax eloquent all day long about Salesforce things. I know it's a a Salesforce webinar here with Salesforce Ben, but I I'm curious. And we work with a lot of regulated accounts, a lot of different, you know, customers. But, Tim, question for you. So I'm curious if when we talk about headless, are is the ecosystem asking more about the tooling? Are they asking more about how to govern and observe this stuff? Where where are you seeing sort of the questions flying when it relates to headless? I think one of the first things that I sort of picked up on, this this was, sort of more towards when, TDX had just occurred, and we saw that there was a little bit of, an announcement around headless. But there was also what was known as and I think you've kind of already covered this. There was also what was known as the agent force experience layer. And there was a little bit of a terminology misunderstanding, I think, and it sounds like too that there has been some terminology changes. So something that I I still hear about a lot is, you know, isn't is Headless three sixty the same as the Agent Force experience layer? And now we're hearing this term, Headless experience layer. I suppose the first thing is, like, you you know, has by the sounds, Agent Force experience layer is now the headless experience layer. That that would be the first question to to clear things up across the board. Is that correct, my understanding? Hello, Philip. You wanna take that? Sure. Yep. So, yes. The first name was Azureforce Experience Layer that we rebranded, but it's essentially the same concept of building once and exposing in multiple surfaces. In fact, we didn't really need a r at all for this. The concept really kind of applies already with, for example, building a lightning component that is available within learning experience and also creating the same UI in Slack. That is already multi surface. Now, you expand this to multiple agents. For example, you can have the same kind of widgets that will be available in chat g p t, in Gemini, GCP, or any other kind of surface. But you don't want to rebuild it each time because with headless it means you're not tied to a single user interface. So you build once and then you can use it everywhere. That's really the concept between behind HXL. Cool. So we've been. doing a lot of theoretical, a lot of thinking, a lot of talking, but, everyone loves demos. We wanna see it, touch it, feel it. So, Sadana, you've been in the weeds lately. We've got, some very special announcements I know you've been working heavily on. So do you wanna maybe show us something so we can touch and feel? You're on mute. muted. Yeah. So let's, bring everything that we have been discussing so far to life. I'm going to share my screen and we will get started. So, before we get too far, I wanted to sort of, like, level set, what Headless three sixty means for a developer today. So Today, a developer can get started with Headless three sixty using three simple steps. We've spoken about this. A lot of you have been practitioners in this space. We've done this. But for the larger group to level set where we are, first things first, it's just a matter of activating the right servers that you need, creating an external client app so you provide the right level of permissions. Again, remember, you are actually making an agent decoding tool act on your behalf to build code, which technically means you need to have the right guardrails to ensure that it needs to have access to only the things that it needs to have access to. That's going to be a step two. Then three, you connect with the coding tool of your choice. It could be Cloud, it could be any coding tool of your choice, but you just add the MCP corrector and you basically get ready to start development. That's basically what a typical process today looks like. I'm going to switch this in interest of time. Today, as I mentioned, once you have registered in the coding tool of your choice, all your connectors are available for the developer to use and you can see that all of these tools can be set up with the right permissions. You can have approval permission set up so developer is always in loop as you're building this and work with the developer workflow that you're trying to get to. Now, this is great. With that level setting, I just also wanted to quickly call out that we do have the SF skills which we spoke about a little bit and I think it's important to call it out. This is your single unified repository for all things Salesforce when it comes to a skills discussion. The reason this is important is going back to something that Felipe just mentioned earlier in the discussion. He mentioned that developers have been building this He mentioned that, you know, developers have been building this this no right blueprint for it. People have been doing their own way of development across the board using these five coding tools. And over time, this is going to lead to AI sprawl and slop. The biggest advantage you get with the skills that we have in here are it's a clear blueprint for these operations. There is a clear defined starting point for developers and all the developers are going to basically use the same blueprint. You have consistency when they start building these applications. We also spoke about plugins. We now have the Salesforce Development plugin here that has a bunch of operations and this can actually be added with simply to your Cloud development environment and it's basically Salesforce ready when it comes to all practical purposes. With that foundation, let's go ahead and look at the use case that we're going to be looking at for today. We have this leading coffee brand called Capricorn Coffee, and they have branches across the globe and they build their loyalty using events. They run these huge partner events across the globe, And using that, they have, you know, they build the loyalty. They bring people, into these meetings, and, that is sort of how they kind of, like, grow their business. And they have, an event that's coming up in, in Moi, and they're gonna do this with their premium partner, which is Coral Cloud Resorts. And you can see that on paper, they have everything planned. They have their venue. They have the attendees registered. But the biggest glitch, that they that they could cannot see from just this is that, you know, who are the, the actual attendees who are at risk? Who needs extra care? Who needs to have, additional outreach? Those are the kind of signals that they do not get directly from these simple registration numbers. Right? So what they really need is a way by which they can bring all of this together as an event planning app, and that basically will help guide these event planners to make sure that the loyalists in the room are being treated well. They go out with, you know, the satisfaction that they attended a good event, and that sort of, like, cascades their loyalty in the long run. Now that looks really nice, but in order to build that, we need to kind of do a lot of things. When I say a lot of things, this is a typical enterprise. They're going to have data spread across several different systems. To start with, we spoke about the premium partner, which is the Coral Cloud resource, and they have the data split across several different systems. You can see that the data coming from Sales Cloud, you know, their, third party systems. There are multiple versions of Coral Cloud resource to start with. So that is problem number one. Next, all of your basic event data is on CRM, which is great. Right? There's an event foundation. They have all the attendee information, sponsor information, venues. All of this is basically on the CRM system of record. But additionally, on top of that, they also have data coming in from third party systems. So for instance, they could have data coming in from legacy systems, brought in via data Cloud or they they can even have things like, you know, booking information that's sitting out in Snowflake, again, brought in via Data Cloud. All of these are critical signals that allow them to plan better in order to make sure that they're providing the right offer to their customers, they're providing the right experience for their customers. So that is also critical detail. And in addition to that, it's not always these straight signals. It could also be these long term trends. Right? So here you have a Tableau analytics semantic model that helps them understand the churn risk based on loyalty tier, which tiers are more prone to churn risk than others. That's an important signal that can help avoid issues even before something occurs. Now, again, these are all gonna be key aspects of the decision making process coming back to this concept of my agent and my app are going to act in such a way that we're going to bring all of this information together, but it's also going to reason and make sure that it provides the right next steps for the event team. Right? But it's not about data addressed and not about just the analytical information that we are seeing thus far. It could also be operational data that's sitting outside of Salesforce. So for instance, we have gift inventory data that's sitting in a third party system. This information is critical because we are planning for an event and we want to send out gifts to our attendees, which means you need to understand what's in stock, what is not available, and how to order them when you need to. All of that detail is currently available via an API. For this company, the Capricorn Coffee, they're able to bring in this information using MuleSoft. They use MuleSoft as a unified API management layer. So they're able to bring in that API. All of that is gold. Right? Information that's gold and all of it could effectively go into that decision making, but it's not easy. Right? Bringing them all together as a developer and tying them all together for the event planner is a task at hand for our developer. The service person asked that one question, how can I know that my event is ready and the developer built one experience for that? Let's look at what that experience will look like. They ended up creating this unified view. First of all, let's pause here and talk about this experience itself. This is not Salesforce traditional lighting UI. As you can see, this is a React application that was built using the Salesforce multi framework concept. You can see here that this was natively built and deployed on Salesforce. It's surfacing up all of the information that we just saw, the basic CRM data, the data Cloud, calculated insights and churned these details, all of the operational data that was coming from the third party systems. All of this is being created and surfaced up on this unified interface. And here, you can see that, we have this Maui Summit, and it's not just a static app anymore. You also have, an agent that is sitting right there answering questions. So you can see here that when asked a question about event readiness, it actually comes back with a rich experience that tells you what where the event stands today, how many activities are there, what the churn risk is, whether the gifts are ready, and it even bakes in the next action right there. So the purpose of understanding readiness is to understand if there are customers at risk and provide them additional outreach, and that is basically baked in into the same experience. This is what we are talking about with respect to opening up the, the consumer experience for Salesforce and how they're able to, like, sort of experience all of the data that's sitting in your lightning, you know, basic CRM system of record and your third party systems and making it available in one single unified interface anywhere they work. Right? So in order to build this, traditionally, you would have to do a lot of context switching. So I'm gonna sort of, like, show you a 15 x sped up version of what this might look like for a developer before headless. Right? That's a lot of context switching across different system, even for a developer to understand what needs to be built and it hurts my eye to even look at it. Someone stopped doing that. Our developer thankfully didn't go that route. They went with the, you know, the headless route to build this. So, basically, they started with a simple prompt. Right? First, they understood what is on the org. So they can using the the MCP servers that they connected to, the Salesforce MCP servers gave them the right context so they're able to understand all of the basic system of record that exists on that org. Well, that's great. But let's also layer in additional intelligence on top of it. Let's go ahead and, look at that problem that we started with. Right? So we saw that, the partner data is spread across different versions. Right? There is different versions of Coral Cloud result that existed across different systems. You need to first create that golden system of record. Right? That is where Informatica helps. Using Informatica, we're able to create that golden record that unifies all of that information and then loads it up into Data three sixty. Now using the Data Cloud MCP servers, we can basically bring all of that information right in the flow of the developers work. Here you can see that they're able to pull in all of the information and also add the Tableau inside semantic model data on top of it. We are essentially layering data one on top of each other. We are starting with the CRM system of record, We added the Data Cloud, goodness on top of it, all of that data that came from your third party systems, added the semantic model, you know, data, again, via the MCP server on top of it. Notice that the developer didn't have to leave the single interface. Everything is connected from right here. All these MCP tools are right at their disposal and they're able to perform whatever they want to do right from one single agentic, ID or agentic tool of their choice. Now once all of that information is available, they can go ahead and start building the agent. And before we get there, I wanted to call out that here is where it becomes interesting. Right? It's before we get there, we also have the third party MCP tools that we spoke about. Right? The the gift inventory information coming from third party system. That is critical data that also needs to go into the event planning. Again, because it's MCP tools and because we've added it as an external service on Salesforce, we are also able to use that as a part of our developer workflow. So the developer has everything. He has a CRM system of record, he has data Cloud data, he has the Tableau insights, and he has third party data coming in from MuleSoft MCPs. Now with that foundation, they're going to go ahead and build the agent. But for this, notice that it's actually using the skill that we just spoke about, the blueprint that allows them to define what a spec should look like, ask for approval, and proceed in a systematic manner. It's not just building agent the way it likes. It's doing it according to the clear instructions specified as part of the skill. And it's not gonna stop there. It's actually building the agent. It's testing it, live testing it, with the org, and you can see that those are the utterances that it used. And so basically, we have an agent that it's picked out, it asked for approval, and once approved, it was able to validate it and then build it with live preview and then, you know, make sure that it is functionally correct, accurate with respect to what we defined it to do. But But we can also go one step further. We can also do a trace to understand if it actually went through the right steps to get there. So you can see here that that's the trace that defines where it should have landed, and you can clearly see where it landed. But this is great, but you can see that it's still a block of text. And we spoke about the fact that, you know, this shouldn't just be a block of text, it needs to be interactive. And this is where headless experience layer comes in. This is what we spoke about. And, Here on headless experience layer, we have the ability to define the widget information using a standard JSON format. Using a JSON, I can define what the card experience should look like and basically have that surfaced up on different user interface. And you can actually visualize this. And so to Felipe's point earlier, we aren't building this for every surface. We're building it once and we're making sure that this is able to scale across any surface that the customer uses. And so that same experience that we spoke, and about in, like, the UI where we showed you that it was actually showing that rich experience, that actually cascades to something like Chachibuty, where you are able to get that exact same experience, the exact same interaction that we saw there. All of it is possible now because of the headless experience layer and how we're able to create that experience using a standardized adaptive card format. And then same thing sort of like expands to other surfaces if you need to either on Slack. So I can go ahead and click on Slack and you can see that it's the same experience here and on Teams as well or any other, channel that your employees actually work. So sort of, like, bringing us home, we saw a lot of stuff in a very short amount of time, but I just want to, like, bring us all home with respect to this one particular view. We saw that the data was coming in as, you know, basic CRM data. We had additional, you know, data context coming from third party system that was loaded into our data lake house by a data three sixty. We had the third party, like, operational data sources that was providing us critical information for even planning. We had Informatica that was providing us with, like that master golden record when there were, like, confusion with respect to which is the right record when it comes to, different systems and having that duplication. Then the Tableau semantic model that provides us with the trends for how things have been performing and where there are weaknesses. All of that was now surfaced up using an agent that was added on our website and we also surface that agent up on multiple different surfaces. And all of that was done using the headless three sixty paradigm, and what you'd end up seeing was an experience that never opened the lightning experience. Right? We never once touched the lightning experience. We never, one, went in and configured anything manually. All this was done using agentic tools, using the MCP tools that we have and the skills that sort of, like, provided the blueprint for the developer to do it directly. So with that, I'm gonna, invite you all back to the stage. Alright. That was, Right. that was some awesome stuff. This is one of those things I think everybody would wanna sit down and spend eight hours in a full day and have you walk it all through. So, maybe a little a little quick teaser there. So, one of the things, that that we wanted to get a quick poll on, you know, we can we can fill all this. We can crank all this stuff out. We can tap into all these tools. One of the things that comes to mind as I see that is how the heck are you gonna govern that entire chain of custody? I've got 17 ingredients. I wanna see everything from Snowflake on the left through data three sixty, through all of our, you know, clouds, through all the products. I wanna see it through Agent Force. I wanna see it pop out the other side and even go into other platform agents. How the heck do I do a chain of custody? So I'm just curious. Are you guys thinking about governance when you are thinking about headless? I think the overwhelming answer is yes. Right? And and I think this this sort of proves one of the points. Right? Developers can crank out a lot of amazing things, and they can do it in a much shorter time frame with these tools. What is very difficult that I don't think anyone has really solved is how do you vibe code the entire chain of custody of of governance and trust? And that's that's one of those things I think that's gonna hit us hit us all hard, and we need to we need to definitely be thinking about. But I wanna just, defer because we we wanna switch to q and a here. But when we think about governance, we think about trust. Philippe, what are your what what is one thing you would advise? What is one thing that you've observed, related to this that you think the audience really, really should know? I think the importance of tests really must be really reinforced here because you build fast and you can do mistakes fast. It will cost you even more. So reinforcing the whole DevOps process, ensuring you have tests with various profile, various various permission sets, and always auditing your security configuration in your org. That's for me is the key thing. Cool. Sadat, Couple things that have yep. Yeah. I I guess, like, the one of the things that I'll piggyback on that is, the whole CICD concept. Right? We now have DevOps testing that allows us to sort of do continuous testing not once during the build process alone, but throughout the entire life cycle. I think, you know, you need to sort of, like, think about testing as a a whole life cycle event. Right? It happens at every stage to kind of, like, ensure that, a, it's right building the right functionality, but, b, it's also ensuring that nothing is broken in the long run, as AI is, like, swiftly creating these features across the board. Nice. So a couple that I'll I'll leave us with, we get back to the skills that we talked about earlier. So built into those skills, and with Vibes are admin and force governance. We've got things like white listing of destructive commands out of the box so you can't accidentally, perform something. When you think about, you know, the difference between tools like Vybz and with others, it's how much you have to maintain those skills. Do they come out of the box? Are they automatically updated? Or do I have to do the updating inside of my cloud, codecs, curse, or whatever? Another I think is that data is staying, protected natively inside of the Salesforce trust boundary. So it's a matter of the commercial agreement of where data lives and what we've agreed to. When you're doing some things in other agents, that agreement is not there between you and them, whereas from a Salesforce perspective, it is. And then we get to that chain of custody that when you look about things like, agent fabric and you look at the totality of that chain of custody, I think, every single action across that entire chain of custody, even out to the agent to agent communication, is logged in the box. So, with that, I know we wanna go ahead and get a lot of q and a. Tim, I wanna, pass it back to you and, and see if you have any closing thoughts or you wanna transition to the q and a. One of the biggest things for me, that I think Salesforce has done extremely well, and you did briefly touch on that too, was the, not needing to think too much around the permissions because Salesforce already handles that. You know, not needing to think too much about, you know, managing those skills because, again, Salesforce already handles that. Something I hadn't really thought about and is it is it and good point, that is around sort of, you know, out of the box wipe sting of of destructive commands. That was something I, yeah, hadn't, had you considered too much, but I can say that would be extremely, powerful when it comes to sort of building in a protected and and, you know, trusted way, so to speak. But, look, you are absolutely right. Hey. Look. First of, thank you all so much for for for sharing everything that you shared so far. We do have a lot of questions, though, so I am gonna jump straight into, q and a, if that's alright. I'm going to again, I'm going to go by the most sort of up voted down just because we do have a lot to go through today. The first one that I can see in this is, can you give me an example of how of some low hanging use cases for Headless three sixty from the perspective of different departments. Again, we're a little bit short on time, so it's maybe something of a little bit of a high level if that's possible. Yeah. I'll give a a quick one. So the headless three sixty MCP specifically is like a a hierarchical. So it does semantic search across all the other MCPs. So it's a it's a quick cut to the chase way for you to start doing things with headless without all of the let me connect to 16 MCPs. The second is that, when you start exploring it for each department, the admin role of being able to just get things done in your org through headless, that is an easy no brainer productivity gain. And then I'll defer to to my counterparts here for a couple other use cases. Yep. I would add maybe just using the the pre the default, the standard, MCP servers, the hosted ones. So you can easily do querying. And then if you wanna do, like, more, destructive operations, you need to be very careful. So maybe just try, for example, the s sublet create and c p server, which will give you access to your org data, of course, based within your user permissions as an easy way to query information, maybe identify trends without building reports and dashboards. Love it. Love it. So then did you have anything to add? Nope. All good. Because you will. yep. No. You're good. You're good. Look. The the next one's an interesting question. I think it's already been briefly touched on, but we couldn't have to to revise because I think it's an important point. And that was, can you help me understand if there is an if there is any advantage or benefit to using Claude plus MCP instead of Claude plus Salesforce CLI for Salesforce core development. I need to add that I have downloaded the SF skills on my computer as well. So I would, I would just respond with an initial. Right? When you think about what each one of these technologies is meant for, the API is a tightly coupled declarative, model. Okay? It's it's meant to handle requests like that. The CLI is meant for the ability for a machine to operate and for for low level tasks to happen. The MCP is intended for a prescriptive description of a tool that an agent can reason with. So if you have really bad descriptions of your MCPs, the agent will naturally screw it up or do poorly. Right? And so you want MCPs, if you want them to act like APIs or act like CLI commands, you want those MCPs to actually be very declared, very prescriptive, not loosey goosey. Right? So I would say MCP is for the agents that are gonna do it, but reasoning is the primary goal. API is all about the tightly tightly declared functionality and the CLI really focused on machine automation. Yeah. You really need both. I don't think you can exclude one or the other. The use case is a bit different, though. Yeah. I'm just maybe gonna leave some time for the other questions because I know we have quite a few of them. Yep. That's it. The the next one actually was was with regards to, you push agent force vibes on one side that then recommend Claude in the doc. What is the message? So what I would say, it's not necessarily you know, marketing does what marketing does, but I I would say it's not necessarily pushing one over the other. I'll give you an example. When you are in Vibes, you can pick your framework. So I can use Claude in Vibes. I can use OpenAI in Vibes. So that's the first thing. You you can keep using Vibes with Claude. Okay? Or you can use Claude standalone to do what you need to do in a headless fashion. I would say a couple of things that we touched on. The fact that skills are inherent. They're always up to date. They're always being maintained. The fact that Vibes runs inside the context of your Salesforce org, not outside of it. So you reduce, you know, just from a security trust perspective. You also get increase in performance if you're running it inside that, or context versus outside. The chattiness of MCPs dies down. Token consumption is gonna die down. So the few advantages, I would say, The goal is not to promote one or the other, but to give you options as to how you do it. And some tool will be best used for certain scenarios and some other tools used for another. Yep. But pick your pick your tool like you pick your, your surface. Absolutely. Yeah. I would just add on that, the message is really openness, to David's point. Yes. You could connect to multiple you you use multiple different models, write on Wipes, or use a different coding tool of your choice. The framework is set up in such a way that you could use the coding tool of your choice, but Wipes has its own inherent advantages. We've seen that in regulated industries specifically when installing local tools on developer machines is, there's friction around that. A browser based ID works in very handy and, Vibes is available right on the sandbox and also to David's point available within the trust boundary. And so it sort of like provides an easy, you know, coding, tool, of choice when it comes to situations like that. And everything is pre break then. Right? The MCP servers are already connected. The skills are already available out of the box. And so there is a very low lift from a developer standpoint to kind of, like, connect all of this and get going in the first place. Everything is connected and, available straight out of the box. And this reminds me of a very good point. I had a chat recently with one of the product managers for Agent Force five. They are thinking about also building additional tools for governance from an administrator point of view. So you'll have the admin being able to look at dashboard of consumption of token, maybe allocate different token counts for different teams. So that's the kind of thing you will see in the future, a centrally managed solution that you couldn't really have with, I would say, an individual license for CloudCoder or Codex or whatever. I like it. That'll be exciting to see. Look. We've got one minute and five seconds left. So I'll do one more question and then and then perhaps wrap. I know we've have briefly touched on this one as well. How far out are we from having a declarative solution for Headless three sixty? Who wants to take that? tough one. No. Greg. Yeah. I I I would say, sorry. Go ahead. oh, I was gonna say, I I know there was a mention of, Agent Force and set up as well, being a part of that. I think, you know, when this I misunderstood that. Was that correct? Yes. That that is part of that. You're gonna see and hear a lot more about, about that setup. I would I would say in terms of declarative solution, you gotta realize that the ability for you to to both programmatically and declaratively, go in and make sure that the tools that you're being set up, that the MCPs that are being set up, the sub agents, and the agent to agent communication is a lot more declarative, is is something that is sort of part of this next wave. There's some that that we can talk about and some that you're gonna hear announced very clearly at Dreamforce. So I don't wanna put the put ourselves in front of the skis there, but lot coming in Dreamforce. I also one of the other questions I popped in the chat is a workshop where you can get started on Headless three sixty for devs. So that is a resource there as well, but stay Great one. Fantastic. We'd love to see it. And look, we are, with. that, out of time. And I really wanna thank all three of you, for for jumping on and and sharing today. This has been an incredibly rich conversation. For those who are interested, if you want to go deeper, there's an on demand webinar, which is called Build Once, Deploy Everywhere, to learn how to define governed logic once and deploy it across React dashboards, Slack, and external AI clients. And of course, to check out developer.salesforce.com to learn more about Salesforce's developer tools. Team, again, thank you so much. This has been a really, really rich session, and I'm sure our audience has learned a lot. I can see a lot of reactions in the in the chat. So, yeah, thank you very much for for making the time to to to speak to us today. And thank you so much for having us. Thank. you. Absolutely. And thank you, everybody, for joining too. I'm I'm sure it's been a a super positive experience for everybody. Thank you. With that, I'll leave you to it. Thanks. Bye. Take care, everybody. Bye.