Artwork

Content provided by Mike Gerholdt. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Mike Gerholdt or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Building With Agentforce and Flow: A Developer’s Hackathon Experience

33:03
 
Share
 

Manage episode 481367322 series 170120
Content provided by Mike Gerholdt. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Mike Gerholdt or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

Today on the Salesforce Admins Podcast, we talk to Melissa Hansen, Co-Founder and Principal Architect at HiFi Consulting Group, RAD Women Curriculum Lead, and Salesforce MVP.

Join us as we chat about her journey from fixing printers to developing an agent-powered scheduling tool in the TDX Agentforce Hackathon on Team MH4.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Melissa Hansen.

How Melissa started her career as a Salesforce Developer

Melissa started her career at a nonprofit, where she was the go-to person for troubleshooting tech issues. “You just become the person who’s best at fixing the printer, and then fixing the database, and then, before you know it, you’re a database administrator,” she says.

These days, Melissa is a developer, a consultant, and a Salesforce MVP for her work with RAD Women. She’s also a member of Team MH4, and I brought her on the pod to hear what building a conference scheduling agent in 16 hours was like from the dev side of things.

Building an agent-powered scheduling tool at the TDX Agentforce Hackathon

Melissa is not someone who wants to be up until midnight coding, but she was so excited about the solution they were building that it was worth the sacrifice. Like most people on the team, it was her first time making something with Agentforce, and this was a great use case to learn more about it.

One of the biggest challenges for Melissa in going from building with code to grounding an agent is that the output is nondeterministic. In other words, if you run an automation, you expect to get the same results every time you give it the same data. Agents don’t work that way, they’ll give you something slightly different every time, and so you need to account for that in how you build and test your solution.

To code or not to code, that is the question

We don’t always have a chance to talk to devs on the pod, so I wanted to hear what Melissa thinks about admin and developer collaboration. For her, the most important conversation to have is around automations.

Flow is a powerful tool for automations, but it’s not the only game in town. Melissa’s seen her share of scary flows for things that would be fairly straightforward in Apex. For her, the biggest determining factor is who will maintain the automation after it’s up and running. As no-code tools like Flow and Agentforce continue to improve, it’s especially important for admins and devs to help each other out.

There are so many more great insights from Melissa on where Agentforce is headed and how to work with developers, so be sure to listen to the full episode. And don’t forget to subscribe to the Salesforce Admins Podcast so you can catch us every Thursday.

Podcast swag

Learn more

Admin Trailblazers Group

Social

Full show transcript

Mike:
Ever gone from changing printer ink to writing Apex code? Melissa Hansen has and she’s here to tell us all about it. So, today’s episode, I am chatting with Melissa Hansen, Salesforce MVP, RAD Women Curriculum lead and longtime champion of nonprofit tech. We talk about her journey from, well, fixing printers to architecting agent-powered scheduling tools and what she learned working on the team of MH to the Power of Four at the TDX Hackathon. Now, she shares her thoughts on building ai, designing for users, and what every admin should ask their developers. So, you don’t want to miss this one. Now, be sure to follow this podcast on whatever platform you listen to so that you never miss an episode. And with that, let’s get Melissa on the podcast.
So, Melissa, welcome to the podcast.

Melissa Hansen:
Thank you so much for having me. I’m excited to be here.

Mike:
I’m excited. This whole series of talking to the MH to the Power of Four team has been such a thrill because I know we’ve done hackathons… by the time this episode comes out, we’ve done a hackathon at TDX in India. I know there’s a virtual hackathon we’ve done. I feel like we’ve done hackathons everywhere, but it’s such an interesting perspective because I was at TDX in San Francisco. I saw some of the teams working, but to sit down with each of you, and hear the perspective and what happened through your eyes is such a neat way of hearing the story and getting the full vibe of what’s going on. So, before we get into that though, Melissa, tell us a little bit about yourself, and what you do in the Salesforce ecosystem and how you got on this Power of Four team.

Melissa Hansen:
Oh, sure. Yeah, I’ve been in the ecosystem for quite a while now. I think just over 15 years, which blows my mind. I was on a path that I think a lot of nonprofit listeners would be familiar with, which is I was in-house at nonprofits starting at the very beginning of my career and slowly moved into the technology side of things. You just become the person who’s best at fixing the printer, and then fixing the database and finding the data. And before it, you’re a database administrator. And I was at an organization that was adopting Salesforce in 2010. Yep, 2010. And that’s how I got started.

I began as an admin and I was at an organization who had some really incredible developers who were really encouraging and mentored me as I started to pick up Apex and the developer side of things. And I just loved it so much. I loved the platform and that has really been my whole career from then becoming a developer. All the way to, in 2020, after being a developer at a nonprofit for about almost 10 years, a coworker and I split off and started our own consulting group to work with other nonprofits and build out Salesforce solutions. So, that’s been my overall arc. Also, I’m a Salesforce MVP Hall of Fame, and a big part of that is because of my work with RAD Women Code.

Mike:
Ah, a connecting Factor. I’ve talked to a lot of RAD Women coders.

Melissa Hansen:
Yes, it’s such a cool organization. I was a coach in the very first round of RAD Women. Angela Mahoney, who Is an incredible connector in our ecosystem, and a lot of your listeners may know of her, invited me to coach. And I had some feedback on the curriculum and ended up taking over the curriculum as this wanted to happen. Yeah, so I’ve been with RAD since the very beginning. I work on the curriculum. And it’s one of my very favorite things that I’ve done, just working with so many women and non-binary folks who are on that same developer journey I was, and who want to learn more about coding. I know this is an admin podcast, but this is our target audience for Rad, too.

Mike:
So, let me talk about that for a second because I feel like that’s an unnecessary division that people have sown. There’s admins that know how to code. Just because you code doesn’t mean you have to identify as a developer.

Melissa Hansen:
Yeah, no, and that’s a great point. And I think in Salesforce in particular, there’s a ton of overlap because the declarative automation tools have become so sophisticated. If you’re building some of these more complex, complicated flows, I mean you’re a developer.

Mike:
And vice versa, too. So, how did you get connected to the other MHers?

Melissa Hansen:
Yes, I do all of them from for quite some time, mostly through the community. I think they’re all MVPs as well. Marisa is a developer. I think she does more on the consulting side now outside of development. But Michelle and Melissa are both people who are at a lot of conferences. And we’ve just been really good friends and colleagues, but we’ve never actually worked directly together prior to the hackathon. So, that was a really cool opportunity.

Mike:
Yeah, it brought a lot of people together.

Melissa Hansen:
It really did. And I’ll admit that I had initial reluctance because I am not a person who wants to be up until midnight coding. Not really my happy space. And so, I was a little, I don’t know, and I’ve got a lot of other stuff to do. But boy, Melissa Hill Dees is very good at convincing you. And I was happy to be convinced because once we started talking about what we might build if we were to do this, we’ve found some really great use cases. And that’s what I got really excited about actually, building something.

Mike:
Yeah, I mean, I talked with Melissa on previous episodes and Marissa about the conference scheduling app, which I’ve worked a lot in scheduling environments with Dreamforce and TDX, and it sounds like such a cool thing. And so, obviously we don’t need to get into the app, but it’s an agent that helps you schedule. I would love to know, because you mentioned developer. And that’s the cool thing is I love that each of you had different roles in this team. And yes, some were overlapping, but because Melissa did call you out, she’s like, Melissa, it sounds like I don’t know who I’m talking about.

Melissa Hansen:
I know we didn’t use last names-

Mike:
Melissa called Melissa the developer, like what? Melissa Hill Dees specifically was like, “Are you going to talk to Melissa Hansen?” I was like, “Yes.” She goes, “Well, you got to talk to her about the developer perspective.” And so, I want to start there. From your developer’s perspective, what was the most technically challenging or exciting part of the agent that you built?

Melissa Hansen:
Well, it was the first time I really got hands-on building an agent outside of things like trailheads or quick little workshops. Which was a big draw for me because of our clients, we don’t have anybody who’s actively using it yet. But we want to be a little bit ahead of them and able to guide and lead when the time comes. So, I was super interested in that part. And I much more motivated when I have a real use case. I wander off if things are too theoretical or sort of like, oh, just learn it for the sake of learning it. I really need something I’m trying to get done. And I loved this use case because we have a similar one for RAD Women about matching up all of our schedules for our coaches, and our learners and our Zoom rooms. So, I could see on the other side of this some really cool applications. I think the most challenging thing conceptually is getting used to non-deterministic results.

Mike:
Tell me. So, before you get into that, because that’s awesome. Please tell me what non-deterministic results mean.

Melissa Hansen:
Yes, definitely. So, typically when you’re writing code or configuring a flow, a lot of times you have inputs and you have outputs, and you have the automation in the middle. And so, if I am taking in a set of inputs, let’s say a few contacts, and maybe some opportunities, and I have some logic in the middle, and then I want something to come out the other end, maybe some contact roles, or who knows? And if I’ve configured everything, and I give it a set of data and I get a result, I expect that if I give it that same set of data again, I will get the same result every time. I could run it a hundred times, I’ll always get the same result. Whereas with these agents and large language models, it’s not giving you the same response every time. It’s trying to come up with the right… if you could see me, right in quotes, the “right” answer for you, but that answer might change, ordering might change, the way it presents, it might change. And that is a very different paradigm than what I’m used to.

Mike:
Yeah, I think one of the things early on when we were talking Agentforce with customers and admins was it’s not a bot. You’re not plugging in if A then C, if B then D. You build upon it as opposed to having exactly follow the same path. So, now I get what you mean.

Melissa Hansen:
And learning how to give it instructions and natural language. When you’re building out these topics, I’m starting to tell it things like, your job is to match these speakers with these time slots. And then you’d start to fill things in of you have to pay attention to the dates of the conference, and leave an hour for lunch, and make sure there’s a passing period and just the series of instructions. And it almost feels weird to just be like, I’m just going to put it in a sentence. That’s no syntax. Okay.

Mike:
Because math class, when you got to the story problems never felt like math class.

Melissa Hansen:
Well, maybe to me it did.

Mike:
I know. Math class always felt like math class to me. Don’t kid me. So, I would like to know in the hackathon, I mean it’s a finite time. And part of that is just you can’t run a hackathon forever because you could run out of people and there’s only so much that we want to see built. I’d love to know in that time, how did you prioritize what to do, what to configure, what to simplify, what to include, what to exclude.

Melissa Hansen:
Yeah. I mean, I think the goal that I have personally and I think that we shared as a team is we wanted to get to something at the end that was… we knew it wouldn’t be perfect in a final product, but something that was really, really working. And it’s fine if it’s messy. It’s fine if we have things we want to go and fix later, but we wanted something that was working. We obviously wanted to learn the tool set and we wanted to work together. So, those were the defining goals that told us where we wanted to go.

We had discussed what our use cases were and we had a loose data model in mind, and then we divided and conquered. We had Michelle and Melissa Hill Dees were working on loading data from their respective conferences. And Marisa was participating in that so that they could be getting the data model and the data loaded together. Well, I was working a little bit with Melissa on actually building the agent. What does this thing even look like? The time crunch is real. One of our first questions was like, okay, how do we get the data once we’ve got it in the org accessible to this agent so that we can ask it to do all this stuff? And I think I started to build a flow. I don’t build nearly as many flows as I write Apex.

Mike:
I mean, that’s what I think every time I go to build a flow, oh, I feel like I’ve not built a flow in, I don’t know, 16 minutes now.

Melissa Hansen:
It’s different. So, I tried for a little bit and then I was like, given the time crunch, you go to the tools you already know and that you’re fastest with. So, at a certain point I was like, I think what’s going to work best is if I just build some Apex methods that pull the data query for the data, filter down to what we want, and then conserve that up to our agent. And one of the things I’m curious about as, because we’re going to continue to develop this thing and hopefully get it to the point where it’s a useful product for lots of conference organizers.

Mike:
Oh, that would be cool.

Melissa Hansen:
Yeah, I’m super excited. So, we have a little bit of a roadmap here, but I’ve got a couple of parts of it that I’m most interested in or that I have the most to do. And one is how much of the work I did was unnecessary, because you go to your comfort zone. I was like, let me write Apex that does this, gets this data, feeds it back. I was like, did I even need that? Can I configure the agent to get the data on its own? Or can I do it in a more lightweight way so that it’s more flexible? Because I definitely went in with my own biases and tool set, and as I was building the agent, I was like, okay, I would think about this differently next time.

Mike:
Well, that leads me to the one question I was thinking about, which is… and I always do this with everything I build. There’s always one part of it that I’m still thinking on, that I’m still like, if I had time, I would do X. One part of that are you still thinking about?

Melissa Hansen:
I’m thinking about the user interaction piece. So, our final product was a conversation that you were having within that sort of agent panel. And you say, “Okay, figure the schedule out for me.” And it would output a table, but right in the chat that would show you who’s scheduled for which room. And you don’t have enough space really in that chat window. You could ask it to make modifications, but it’s not always clear what’s happening. So, it’s just not the right visual paradigm. And so, the thing that I’m thinking about is getting it into a flow, into a screen flow so that the user-

Mike:
[inaudible 00:15:55].

Melissa Hansen:
Oh, sorry.

Mike:
No, I was just thinking this through.

Melissa Hansen:
Yeah. So, that the user could launch their screen flow, maybe answer a couple of questions up front, and then we invoke the agent to do the really cool automated scheduling template for us, feed it back to the flow, and then the user has a table that they can actually work with and make modifications to make adjustments here and there. I’d really be able to see the whole thing in a way that makes sense before they sort of agree and commit, and then save that scheduling.

Mike:
Yeah, I think one thing for us to consider is you go and listen to this podcast when I was talking to Marissa of five years from now or 10 years from now, we’re going to say, “Oh, wow. So, that’s like back when Agentforce, they just had a prompt window.” Back when we talk about Salesforce. Do you remember when the interface was WYSIWYG, and we could finally drag and drop fields onto a page and see them?

Melissa Hansen:
Oh, yeah.

Mike:
[inaudible 00:17:00] years ago.

Melissa Hansen:
It has changed so much. Yeah. I was at a presentation recently and somebody had a screenshot of not just classic but classic from a long time ago.

Mike:
With tabs.

Melissa Hansen:
Yes. And you’re just like, “Oh, yeah, that used to be my every day.”

Mike:
Yeah, yeah. Yep. And that used to be new.

Melissa Hansen:
Yes, it was [inaudible 00:17:23] new.

Mike:
Wow, that’s the future. I was going to joke, you mentioned your gateway to becoming a developer was learning how to change printer ink, perhaps don’t do that or do. I think it’s interesting, I have a friend. I asked him, “How did you get into…” he was a consultant and he’s now a CIO for a company. I said, “How’d you get into all this?” He goes, “Well, when my company got Salesforce, I was really good at Facebook.” And I think even another 10 years from now, it’s going to sound really interesting for a bunch of people when they ask us, “How did you get into Salesforce?” I was good at Facebook. I knew how to change the printer ink.

Melissa Hansen:
How are these things related?

Mike:
Help me out. But I do think, so I came from a non-technical background. I came from a sales background. I don’t want to say a lot of admins, but a fair share of admins who really embrace the non-technical side of Salesforce that use the standard platform tools, understand it at its base level and look at things differently than perhaps a would who’s been trained in code or looks at the platform first. I’d love to know, what’s one thing you wish admins asked when working with developers?

Melissa Hansen:
We’ll see if this answers your question. I think the conversation, especially since flow has become so robust, so the conversation between admins and developers is often, not exclusively, but a lot of times about what is the best place for this automation to live? Because there’s way more things now that really could go either way. You could do it in a flow, you could do it in Apex. And I think there’s sometimes a bias on the admin side to if you can build it in flow, build it in flow. And I have definitely seen some Flows that are a little bit scary. And not scary because the person who built them didn’t know what they were doing, or did it poorly or anything like that. It’s just the sheer complexity and management of a flow to do something that in some cases would be very straightforward if done in code.

And so, I think especially in an organization that has code already, that has the ability to support programmatic automation, having good conversations about what is… not just can it be in flow, but should it be in flow? And that is going to continue to change as features come in and shift. But I think that’s a fun conversation that’s ongoing. And it goes both ways because my bias is probably to put more things in Apex than I should. And so, I need someone to say, “Actually flow’s getting really good at that. We should look at it again.”

Mike:
Well, and it’s the maintainability, too. If I was an admin, and I’ve worked with consultants before where you sit down and it’s, well, who is going… at the end of the day, who’s going to maintain this? Because for some stuff we could have built a trigger. They’re never going to be able to maintain a trigger. And so, if you build it in flow, it’s harder, yes, but it’s maintainable.

Melissa Hansen:
Yeah. Yeah. And that who’s going to be in charge of it? Is one of the biggest questions because absolutely, if there isn’t a developer on staff or on retainer than taking more time to build a flow to have a chain of declarative automation. Yeah, that’s going to be the right answer.

Mike:
Yeah. So, I’ll ask you this. As a developer, how do you see AI tools like Agentforce changing what the day-to-day is for admins and developers?

Melissa Hansen:
I mean, it’s changing so much so quickly. Most of my actual hands-on usage is with Agentforce for developers. That tool set and related AI tools that are geared towards developers have already changed my day-to-day so much. I have conversations with them about code that I’m refactoring, or writing tests. Or a very common thing for me is I’m going into a new environment and now I can have the agent summarize what is happening in these classes and give me something that would’ve taken me quite a lot longer to just try and pour through, and read and synthesize on my own. It gives me a good jumpstart.

And you’re starting to see that more on the declarative side as well, where we’re going to have agents where you can say, “Summarize this data model for me,” or, “How are these objects related?” And my favorite would be, what automation is happening after I save an opportunity to have something that could look across your system, summarize both declarative and programmatic automation and say, well, there’s this flow that fires, and these two triggers and a field update. You’re like, wow, [inaudible 00:22:50] a bit of a much harder question to answer. And it feels like that’s the direction we’re going in. It’s like this little assistant that you have that you can ask all kinds of questions.

Mike:
Yeah, I mean, because there’s such a big platform behind it. So, I want to ask the next level question for one of those. Internally on our team, I did a ChatGPT demo for some of our marketing people to show them, here’s how I do this, and essentially, here’s how I use this to make me a better writer. And one of them very astutely asked me like, “Mike, how many hours a day do you think you save?” And I don’t know. I mean I use it extensively to help me write and edit better to compare. It’s easy to compare big blocks of sentences and paragraphs together. What I’m getting at for you is you mentioned having it and having AI compare code and tell you what’s going on in the class. How long would that have normally taken you? What’s the time saving you’re getting by just dumping in some code and saying, “What’s going on here?”

Melissa Hansen:
I mean, it’s definitely on the order of hours. It very much depends of course. If I’m looking at something pretty straightforward, take me a few minutes. Or just made it a lot more pleasant potentially. But for something that is pretty gnarly and I need a lot of context to even get started, it can absolutely be, I’m like, wow, that helping me refactor and summarizing things cut two hours off of what would’ve been a six-hour project.

Mike:
Holy cow.

Melissa Hansen:
Possibly more. And there’s some days where I don’t end up needing a lot of that, and things are as usual. And then there are some days where it’s like, that would’ve taken me twice as long. Because you still need to validate with telling you. We’re not at the point, if we’ll ever be, where you could just say, “Refactor this class, compiled, I’m done.”

Mike:
Right. Well, I mean that was exactly one of the use cases I was going through with our team. She pointed out, she’s like, “Yeah, but that’s still not right.” And I was like, “I know. That’s the human in the loop part.” And I told her, I go, “That’s where you’re the human.” And we kept rewriting a sentence and it just never got right. It got really good, but it just never got right. And I was like, well, that’s because it’s not there yet, but it got us 80% of the way there. It’s like Google Maps. When you put in an address and it’s like when you get here, you just got to figure out the rest of the way how to get to the front door from the parking lot.

Melissa Hansen:
Yeah, address is on the wrong street, but actually the entrance is over there. But yeah, figure that out.

Mike:
Yep. Yep. One of the questions, so this came happenstance during the Melissa Hill Dees episode. And when I asked it, I realized I got to ask everybody this question. So, I asked everybody this, if you could build an agent to help every admin do one thing better, what would it be?

Melissa Hansen:
That’s a good question and I really need to think about it. I’d probably go to data model.

Mike:
Oh, all right.

Melissa Hansen:
Yeah, something that is aware enough of your organization, what it does, packages you’ve got, the objects you’ve got, that when you’re solutioning and you’re proposing, maybe we’re creating some new objects or maybe it’s existing objects and we’re going to create some fields. Something that can ride along and really help you make sure that the way that you’re architecting that object in those fields makes sense. And I would take it a step further and have it really help with the self-documentation side of that as well.

Mike:
Yes. Oh, my God, Somebody finally said it. I was hoping somebody would say it. You said it.

Melissa Hansen:
I think those labels, those descriptions, the help text. It’s always been helpful and important to have those things for different people coming in and learning the organization for helping users. But as we use more and more agents, it becomes even more important because those tools are using your documentation, that metadata to understand and give you better answers. So, I can ask it, “Hey, give me all the contacts who are this and this kind of member,” and it can give me a good answer if the fields that tell you what that means and what kind of memberships are, if those things are annotated and filled in, it’s going to give me a really good answer. If they’re not, it might be guessing and it might pull an old field from a package we don’t use, and give you a really wrong answer.

Mike:
I would totally use your agent and ask me, based on the data architecture I’ve given you, can I build this report?

Melissa Hansen:
Oh, that’s a good one.

Mike:
Because we all have an Achilles heel. Reporting is my Achilles heel. And for as much as I’d love getting reports out, I’m always afraid when I’m architecting an app, that I’m building it in such a way that I’m not going to be able to get the reports that I want. I would love that. So, I would love to use your agent to be like, okay, before we commit this, I’d love to have it say, “Here’s the reports you can build and give me some sample reports.”

Melissa Hansen:
And that’s such a great example as a time saver too, because typically that’s always a validation step after you’ve built, can we get the report? Can I build the report? But if you can answer that question before you implement the data model and make all those connections, you can fix things a lot earlier and a lot quicker.

Mike:
Or have to make all of those really crazy custom report types. Yeah. That was it. Melissa, this is a fun conversation. I’m glad you came on and gave us some perspective on the agent that you guys built and some of the things you’re working on. And I had a million more questions, but-

Melissa Hansen:
Time is finite.

Mike:
Time-

Melissa Hansen:
Our time is finite anyways.

Mike:
Time like the hackathon isn’t on our side. But I think it’s really cool what you guys built, and I would love to see something like that come out. I think for people that have listened to the podcast and they’re like, “Oh, it’s a conference schedule thing.” Yeah, I don’t think we’d use that. Folks, it’s like meetings. If you’ve ever got two or three people, you got to schedule meetings for this thing, there’s so many relatable uses for it.

Melissa Hansen:
Yeah, absolutely. I can think of a lot of places where this would come in handy. And even, I think just learning it is such the case that once you get into it and see how it was built, then you start to see the other applications. It’s like, oh, but we could use this for managing our conference rooms or a whole variety of other things. Once you see the kinds of questions that can answer for you, given data that would take humans a long time to munch through and align.

Mike:
Yeah. And you only had a finite amount of data to work with as opposed to what an organization may have after even a few years.

Melissa Hansen:
Right. Yeah, there’s some rich data sets out there, which is great because yeah, we’re going to continue to develop this thing and hopefully have a useful tool that other members of the community can utilize. I’m thinking about taking it to the next community sprint, and seeing if we can get some more help and more use cases over there because such a cool, cool event.

Mike:
Yeah, everybody needs to share out those use cases. Let’s end on a high note. What’s one word your teammates would use to describe you?

Melissa Hansen:
It’s a hard question. Let’s go with analytical.

Mike:
Oh, I feel you were very analytical in coming up with that answer.

Melissa Hansen:
That’s fun.

Mike:
That’s great. Well, Melissa, thank you for being on the podcast. This is wonderful. I feel you’ve done a lot to inspire people to just sit down and be curious with an agent, and see what they can and can’t do, and just be creative with it.

Melissa Hansen:
Well, cool. Thank you so much for having me on, Mike. This was really fun.

Mike:
Big thanks to Melissa for joining us and sharing her thoughtful insights, not just on building with AI, but on collaborating across roles and using tech to empower others. If you enjoyed this conversation, share it with a fellow admin or developer. And don’t forget, you can always find more resources at admin.salesforce.com, including a transcript of today’s show. Be sure to connect with other Salesforce admins in the Trailblazer community. And as always, until next time, we’ll see you in the cloud.

The post Building With Agentforce and Flow: A Developer’s Hackathon Experience appeared first on Salesforce Admins.

  continue reading

330 episodes

Artwork
iconShare
 
Manage episode 481367322 series 170120
Content provided by Mike Gerholdt. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Mike Gerholdt or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

Today on the Salesforce Admins Podcast, we talk to Melissa Hansen, Co-Founder and Principal Architect at HiFi Consulting Group, RAD Women Curriculum Lead, and Salesforce MVP.

Join us as we chat about her journey from fixing printers to developing an agent-powered scheduling tool in the TDX Agentforce Hackathon on Team MH4.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Melissa Hansen.

How Melissa started her career as a Salesforce Developer

Melissa started her career at a nonprofit, where she was the go-to person for troubleshooting tech issues. “You just become the person who’s best at fixing the printer, and then fixing the database, and then, before you know it, you’re a database administrator,” she says.

These days, Melissa is a developer, a consultant, and a Salesforce MVP for her work with RAD Women. She’s also a member of Team MH4, and I brought her on the pod to hear what building a conference scheduling agent in 16 hours was like from the dev side of things.

Building an agent-powered scheduling tool at the TDX Agentforce Hackathon

Melissa is not someone who wants to be up until midnight coding, but she was so excited about the solution they were building that it was worth the sacrifice. Like most people on the team, it was her first time making something with Agentforce, and this was a great use case to learn more about it.

One of the biggest challenges for Melissa in going from building with code to grounding an agent is that the output is nondeterministic. In other words, if you run an automation, you expect to get the same results every time you give it the same data. Agents don’t work that way, they’ll give you something slightly different every time, and so you need to account for that in how you build and test your solution.

To code or not to code, that is the question

We don’t always have a chance to talk to devs on the pod, so I wanted to hear what Melissa thinks about admin and developer collaboration. For her, the most important conversation to have is around automations.

Flow is a powerful tool for automations, but it’s not the only game in town. Melissa’s seen her share of scary flows for things that would be fairly straightforward in Apex. For her, the biggest determining factor is who will maintain the automation after it’s up and running. As no-code tools like Flow and Agentforce continue to improve, it’s especially important for admins and devs to help each other out.

There are so many more great insights from Melissa on where Agentforce is headed and how to work with developers, so be sure to listen to the full episode. And don’t forget to subscribe to the Salesforce Admins Podcast so you can catch us every Thursday.

Podcast swag

Learn more

Admin Trailblazers Group

Social

Full show transcript

Mike:
Ever gone from changing printer ink to writing Apex code? Melissa Hansen has and she’s here to tell us all about it. So, today’s episode, I am chatting with Melissa Hansen, Salesforce MVP, RAD Women Curriculum lead and longtime champion of nonprofit tech. We talk about her journey from, well, fixing printers to architecting agent-powered scheduling tools and what she learned working on the team of MH to the Power of Four at the TDX Hackathon. Now, she shares her thoughts on building ai, designing for users, and what every admin should ask their developers. So, you don’t want to miss this one. Now, be sure to follow this podcast on whatever platform you listen to so that you never miss an episode. And with that, let’s get Melissa on the podcast.
So, Melissa, welcome to the podcast.

Melissa Hansen:
Thank you so much for having me. I’m excited to be here.

Mike:
I’m excited. This whole series of talking to the MH to the Power of Four team has been such a thrill because I know we’ve done hackathons… by the time this episode comes out, we’ve done a hackathon at TDX in India. I know there’s a virtual hackathon we’ve done. I feel like we’ve done hackathons everywhere, but it’s such an interesting perspective because I was at TDX in San Francisco. I saw some of the teams working, but to sit down with each of you, and hear the perspective and what happened through your eyes is such a neat way of hearing the story and getting the full vibe of what’s going on. So, before we get into that though, Melissa, tell us a little bit about yourself, and what you do in the Salesforce ecosystem and how you got on this Power of Four team.

Melissa Hansen:
Oh, sure. Yeah, I’ve been in the ecosystem for quite a while now. I think just over 15 years, which blows my mind. I was on a path that I think a lot of nonprofit listeners would be familiar with, which is I was in-house at nonprofits starting at the very beginning of my career and slowly moved into the technology side of things. You just become the person who’s best at fixing the printer, and then fixing the database and finding the data. And before it, you’re a database administrator. And I was at an organization that was adopting Salesforce in 2010. Yep, 2010. And that’s how I got started.

I began as an admin and I was at an organization who had some really incredible developers who were really encouraging and mentored me as I started to pick up Apex and the developer side of things. And I just loved it so much. I loved the platform and that has really been my whole career from then becoming a developer. All the way to, in 2020, after being a developer at a nonprofit for about almost 10 years, a coworker and I split off and started our own consulting group to work with other nonprofits and build out Salesforce solutions. So, that’s been my overall arc. Also, I’m a Salesforce MVP Hall of Fame, and a big part of that is because of my work with RAD Women Code.

Mike:
Ah, a connecting Factor. I’ve talked to a lot of RAD Women coders.

Melissa Hansen:
Yes, it’s such a cool organization. I was a coach in the very first round of RAD Women. Angela Mahoney, who Is an incredible connector in our ecosystem, and a lot of your listeners may know of her, invited me to coach. And I had some feedback on the curriculum and ended up taking over the curriculum as this wanted to happen. Yeah, so I’ve been with RAD since the very beginning. I work on the curriculum. And it’s one of my very favorite things that I’ve done, just working with so many women and non-binary folks who are on that same developer journey I was, and who want to learn more about coding. I know this is an admin podcast, but this is our target audience for Rad, too.

Mike:
So, let me talk about that for a second because I feel like that’s an unnecessary division that people have sown. There’s admins that know how to code. Just because you code doesn’t mean you have to identify as a developer.

Melissa Hansen:
Yeah, no, and that’s a great point. And I think in Salesforce in particular, there’s a ton of overlap because the declarative automation tools have become so sophisticated. If you’re building some of these more complex, complicated flows, I mean you’re a developer.

Mike:
And vice versa, too. So, how did you get connected to the other MHers?

Melissa Hansen:
Yes, I do all of them from for quite some time, mostly through the community. I think they’re all MVPs as well. Marisa is a developer. I think she does more on the consulting side now outside of development. But Michelle and Melissa are both people who are at a lot of conferences. And we’ve just been really good friends and colleagues, but we’ve never actually worked directly together prior to the hackathon. So, that was a really cool opportunity.

Mike:
Yeah, it brought a lot of people together.

Melissa Hansen:
It really did. And I’ll admit that I had initial reluctance because I am not a person who wants to be up until midnight coding. Not really my happy space. And so, I was a little, I don’t know, and I’ve got a lot of other stuff to do. But boy, Melissa Hill Dees is very good at convincing you. And I was happy to be convinced because once we started talking about what we might build if we were to do this, we’ve found some really great use cases. And that’s what I got really excited about actually, building something.

Mike:
Yeah, I mean, I talked with Melissa on previous episodes and Marissa about the conference scheduling app, which I’ve worked a lot in scheduling environments with Dreamforce and TDX, and it sounds like such a cool thing. And so, obviously we don’t need to get into the app, but it’s an agent that helps you schedule. I would love to know, because you mentioned developer. And that’s the cool thing is I love that each of you had different roles in this team. And yes, some were overlapping, but because Melissa did call you out, she’s like, Melissa, it sounds like I don’t know who I’m talking about.

Melissa Hansen:
I know we didn’t use last names-

Mike:
Melissa called Melissa the developer, like what? Melissa Hill Dees specifically was like, “Are you going to talk to Melissa Hansen?” I was like, “Yes.” She goes, “Well, you got to talk to her about the developer perspective.” And so, I want to start there. From your developer’s perspective, what was the most technically challenging or exciting part of the agent that you built?

Melissa Hansen:
Well, it was the first time I really got hands-on building an agent outside of things like trailheads or quick little workshops. Which was a big draw for me because of our clients, we don’t have anybody who’s actively using it yet. But we want to be a little bit ahead of them and able to guide and lead when the time comes. So, I was super interested in that part. And I much more motivated when I have a real use case. I wander off if things are too theoretical or sort of like, oh, just learn it for the sake of learning it. I really need something I’m trying to get done. And I loved this use case because we have a similar one for RAD Women about matching up all of our schedules for our coaches, and our learners and our Zoom rooms. So, I could see on the other side of this some really cool applications. I think the most challenging thing conceptually is getting used to non-deterministic results.

Mike:
Tell me. So, before you get into that, because that’s awesome. Please tell me what non-deterministic results mean.

Melissa Hansen:
Yes, definitely. So, typically when you’re writing code or configuring a flow, a lot of times you have inputs and you have outputs, and you have the automation in the middle. And so, if I am taking in a set of inputs, let’s say a few contacts, and maybe some opportunities, and I have some logic in the middle, and then I want something to come out the other end, maybe some contact roles, or who knows? And if I’ve configured everything, and I give it a set of data and I get a result, I expect that if I give it that same set of data again, I will get the same result every time. I could run it a hundred times, I’ll always get the same result. Whereas with these agents and large language models, it’s not giving you the same response every time. It’s trying to come up with the right… if you could see me, right in quotes, the “right” answer for you, but that answer might change, ordering might change, the way it presents, it might change. And that is a very different paradigm than what I’m used to.

Mike:
Yeah, I think one of the things early on when we were talking Agentforce with customers and admins was it’s not a bot. You’re not plugging in if A then C, if B then D. You build upon it as opposed to having exactly follow the same path. So, now I get what you mean.

Melissa Hansen:
And learning how to give it instructions and natural language. When you’re building out these topics, I’m starting to tell it things like, your job is to match these speakers with these time slots. And then you’d start to fill things in of you have to pay attention to the dates of the conference, and leave an hour for lunch, and make sure there’s a passing period and just the series of instructions. And it almost feels weird to just be like, I’m just going to put it in a sentence. That’s no syntax. Okay.

Mike:
Because math class, when you got to the story problems never felt like math class.

Melissa Hansen:
Well, maybe to me it did.

Mike:
I know. Math class always felt like math class to me. Don’t kid me. So, I would like to know in the hackathon, I mean it’s a finite time. And part of that is just you can’t run a hackathon forever because you could run out of people and there’s only so much that we want to see built. I’d love to know in that time, how did you prioritize what to do, what to configure, what to simplify, what to include, what to exclude.

Melissa Hansen:
Yeah. I mean, I think the goal that I have personally and I think that we shared as a team is we wanted to get to something at the end that was… we knew it wouldn’t be perfect in a final product, but something that was really, really working. And it’s fine if it’s messy. It’s fine if we have things we want to go and fix later, but we wanted something that was working. We obviously wanted to learn the tool set and we wanted to work together. So, those were the defining goals that told us where we wanted to go.

We had discussed what our use cases were and we had a loose data model in mind, and then we divided and conquered. We had Michelle and Melissa Hill Dees were working on loading data from their respective conferences. And Marisa was participating in that so that they could be getting the data model and the data loaded together. Well, I was working a little bit with Melissa on actually building the agent. What does this thing even look like? The time crunch is real. One of our first questions was like, okay, how do we get the data once we’ve got it in the org accessible to this agent so that we can ask it to do all this stuff? And I think I started to build a flow. I don’t build nearly as many flows as I write Apex.

Mike:
I mean, that’s what I think every time I go to build a flow, oh, I feel like I’ve not built a flow in, I don’t know, 16 minutes now.

Melissa Hansen:
It’s different. So, I tried for a little bit and then I was like, given the time crunch, you go to the tools you already know and that you’re fastest with. So, at a certain point I was like, I think what’s going to work best is if I just build some Apex methods that pull the data query for the data, filter down to what we want, and then conserve that up to our agent. And one of the things I’m curious about as, because we’re going to continue to develop this thing and hopefully get it to the point where it’s a useful product for lots of conference organizers.

Mike:
Oh, that would be cool.

Melissa Hansen:
Yeah, I’m super excited. So, we have a little bit of a roadmap here, but I’ve got a couple of parts of it that I’m most interested in or that I have the most to do. And one is how much of the work I did was unnecessary, because you go to your comfort zone. I was like, let me write Apex that does this, gets this data, feeds it back. I was like, did I even need that? Can I configure the agent to get the data on its own? Or can I do it in a more lightweight way so that it’s more flexible? Because I definitely went in with my own biases and tool set, and as I was building the agent, I was like, okay, I would think about this differently next time.

Mike:
Well, that leads me to the one question I was thinking about, which is… and I always do this with everything I build. There’s always one part of it that I’m still thinking on, that I’m still like, if I had time, I would do X. One part of that are you still thinking about?

Melissa Hansen:
I’m thinking about the user interaction piece. So, our final product was a conversation that you were having within that sort of agent panel. And you say, “Okay, figure the schedule out for me.” And it would output a table, but right in the chat that would show you who’s scheduled for which room. And you don’t have enough space really in that chat window. You could ask it to make modifications, but it’s not always clear what’s happening. So, it’s just not the right visual paradigm. And so, the thing that I’m thinking about is getting it into a flow, into a screen flow so that the user-

Mike:
[inaudible 00:15:55].

Melissa Hansen:
Oh, sorry.

Mike:
No, I was just thinking this through.

Melissa Hansen:
Yeah. So, that the user could launch their screen flow, maybe answer a couple of questions up front, and then we invoke the agent to do the really cool automated scheduling template for us, feed it back to the flow, and then the user has a table that they can actually work with and make modifications to make adjustments here and there. I’d really be able to see the whole thing in a way that makes sense before they sort of agree and commit, and then save that scheduling.

Mike:
Yeah, I think one thing for us to consider is you go and listen to this podcast when I was talking to Marissa of five years from now or 10 years from now, we’re going to say, “Oh, wow. So, that’s like back when Agentforce, they just had a prompt window.” Back when we talk about Salesforce. Do you remember when the interface was WYSIWYG, and we could finally drag and drop fields onto a page and see them?

Melissa Hansen:
Oh, yeah.

Mike:
[inaudible 00:17:00] years ago.

Melissa Hansen:
It has changed so much. Yeah. I was at a presentation recently and somebody had a screenshot of not just classic but classic from a long time ago.

Mike:
With tabs.

Melissa Hansen:
Yes. And you’re just like, “Oh, yeah, that used to be my every day.”

Mike:
Yeah, yeah. Yep. And that used to be new.

Melissa Hansen:
Yes, it was [inaudible 00:17:23] new.

Mike:
Wow, that’s the future. I was going to joke, you mentioned your gateway to becoming a developer was learning how to change printer ink, perhaps don’t do that or do. I think it’s interesting, I have a friend. I asked him, “How did you get into…” he was a consultant and he’s now a CIO for a company. I said, “How’d you get into all this?” He goes, “Well, when my company got Salesforce, I was really good at Facebook.” And I think even another 10 years from now, it’s going to sound really interesting for a bunch of people when they ask us, “How did you get into Salesforce?” I was good at Facebook. I knew how to change the printer ink.

Melissa Hansen:
How are these things related?

Mike:
Help me out. But I do think, so I came from a non-technical background. I came from a sales background. I don’t want to say a lot of admins, but a fair share of admins who really embrace the non-technical side of Salesforce that use the standard platform tools, understand it at its base level and look at things differently than perhaps a would who’s been trained in code or looks at the platform first. I’d love to know, what’s one thing you wish admins asked when working with developers?

Melissa Hansen:
We’ll see if this answers your question. I think the conversation, especially since flow has become so robust, so the conversation between admins and developers is often, not exclusively, but a lot of times about what is the best place for this automation to live? Because there’s way more things now that really could go either way. You could do it in a flow, you could do it in Apex. And I think there’s sometimes a bias on the admin side to if you can build it in flow, build it in flow. And I have definitely seen some Flows that are a little bit scary. And not scary because the person who built them didn’t know what they were doing, or did it poorly or anything like that. It’s just the sheer complexity and management of a flow to do something that in some cases would be very straightforward if done in code.

And so, I think especially in an organization that has code already, that has the ability to support programmatic automation, having good conversations about what is… not just can it be in flow, but should it be in flow? And that is going to continue to change as features come in and shift. But I think that’s a fun conversation that’s ongoing. And it goes both ways because my bias is probably to put more things in Apex than I should. And so, I need someone to say, “Actually flow’s getting really good at that. We should look at it again.”

Mike:
Well, and it’s the maintainability, too. If I was an admin, and I’ve worked with consultants before where you sit down and it’s, well, who is going… at the end of the day, who’s going to maintain this? Because for some stuff we could have built a trigger. They’re never going to be able to maintain a trigger. And so, if you build it in flow, it’s harder, yes, but it’s maintainable.

Melissa Hansen:
Yeah. Yeah. And that who’s going to be in charge of it? Is one of the biggest questions because absolutely, if there isn’t a developer on staff or on retainer than taking more time to build a flow to have a chain of declarative automation. Yeah, that’s going to be the right answer.

Mike:
Yeah. So, I’ll ask you this. As a developer, how do you see AI tools like Agentforce changing what the day-to-day is for admins and developers?

Melissa Hansen:
I mean, it’s changing so much so quickly. Most of my actual hands-on usage is with Agentforce for developers. That tool set and related AI tools that are geared towards developers have already changed my day-to-day so much. I have conversations with them about code that I’m refactoring, or writing tests. Or a very common thing for me is I’m going into a new environment and now I can have the agent summarize what is happening in these classes and give me something that would’ve taken me quite a lot longer to just try and pour through, and read and synthesize on my own. It gives me a good jumpstart.

And you’re starting to see that more on the declarative side as well, where we’re going to have agents where you can say, “Summarize this data model for me,” or, “How are these objects related?” And my favorite would be, what automation is happening after I save an opportunity to have something that could look across your system, summarize both declarative and programmatic automation and say, well, there’s this flow that fires, and these two triggers and a field update. You’re like, wow, [inaudible 00:22:50] a bit of a much harder question to answer. And it feels like that’s the direction we’re going in. It’s like this little assistant that you have that you can ask all kinds of questions.

Mike:
Yeah, I mean, because there’s such a big platform behind it. So, I want to ask the next level question for one of those. Internally on our team, I did a ChatGPT demo for some of our marketing people to show them, here’s how I do this, and essentially, here’s how I use this to make me a better writer. And one of them very astutely asked me like, “Mike, how many hours a day do you think you save?” And I don’t know. I mean I use it extensively to help me write and edit better to compare. It’s easy to compare big blocks of sentences and paragraphs together. What I’m getting at for you is you mentioned having it and having AI compare code and tell you what’s going on in the class. How long would that have normally taken you? What’s the time saving you’re getting by just dumping in some code and saying, “What’s going on here?”

Melissa Hansen:
I mean, it’s definitely on the order of hours. It very much depends of course. If I’m looking at something pretty straightforward, take me a few minutes. Or just made it a lot more pleasant potentially. But for something that is pretty gnarly and I need a lot of context to even get started, it can absolutely be, I’m like, wow, that helping me refactor and summarizing things cut two hours off of what would’ve been a six-hour project.

Mike:
Holy cow.

Melissa Hansen:
Possibly more. And there’s some days where I don’t end up needing a lot of that, and things are as usual. And then there are some days where it’s like, that would’ve taken me twice as long. Because you still need to validate with telling you. We’re not at the point, if we’ll ever be, where you could just say, “Refactor this class, compiled, I’m done.”

Mike:
Right. Well, I mean that was exactly one of the use cases I was going through with our team. She pointed out, she’s like, “Yeah, but that’s still not right.” And I was like, “I know. That’s the human in the loop part.” And I told her, I go, “That’s where you’re the human.” And we kept rewriting a sentence and it just never got right. It got really good, but it just never got right. And I was like, well, that’s because it’s not there yet, but it got us 80% of the way there. It’s like Google Maps. When you put in an address and it’s like when you get here, you just got to figure out the rest of the way how to get to the front door from the parking lot.

Melissa Hansen:
Yeah, address is on the wrong street, but actually the entrance is over there. But yeah, figure that out.

Mike:
Yep. Yep. One of the questions, so this came happenstance during the Melissa Hill Dees episode. And when I asked it, I realized I got to ask everybody this question. So, I asked everybody this, if you could build an agent to help every admin do one thing better, what would it be?

Melissa Hansen:
That’s a good question and I really need to think about it. I’d probably go to data model.

Mike:
Oh, all right.

Melissa Hansen:
Yeah, something that is aware enough of your organization, what it does, packages you’ve got, the objects you’ve got, that when you’re solutioning and you’re proposing, maybe we’re creating some new objects or maybe it’s existing objects and we’re going to create some fields. Something that can ride along and really help you make sure that the way that you’re architecting that object in those fields makes sense. And I would take it a step further and have it really help with the self-documentation side of that as well.

Mike:
Yes. Oh, my God, Somebody finally said it. I was hoping somebody would say it. You said it.

Melissa Hansen:
I think those labels, those descriptions, the help text. It’s always been helpful and important to have those things for different people coming in and learning the organization for helping users. But as we use more and more agents, it becomes even more important because those tools are using your documentation, that metadata to understand and give you better answers. So, I can ask it, “Hey, give me all the contacts who are this and this kind of member,” and it can give me a good answer if the fields that tell you what that means and what kind of memberships are, if those things are annotated and filled in, it’s going to give me a really good answer. If they’re not, it might be guessing and it might pull an old field from a package we don’t use, and give you a really wrong answer.

Mike:
I would totally use your agent and ask me, based on the data architecture I’ve given you, can I build this report?

Melissa Hansen:
Oh, that’s a good one.

Mike:
Because we all have an Achilles heel. Reporting is my Achilles heel. And for as much as I’d love getting reports out, I’m always afraid when I’m architecting an app, that I’m building it in such a way that I’m not going to be able to get the reports that I want. I would love that. So, I would love to use your agent to be like, okay, before we commit this, I’d love to have it say, “Here’s the reports you can build and give me some sample reports.”

Melissa Hansen:
And that’s such a great example as a time saver too, because typically that’s always a validation step after you’ve built, can we get the report? Can I build the report? But if you can answer that question before you implement the data model and make all those connections, you can fix things a lot earlier and a lot quicker.

Mike:
Or have to make all of those really crazy custom report types. Yeah. That was it. Melissa, this is a fun conversation. I’m glad you came on and gave us some perspective on the agent that you guys built and some of the things you’re working on. And I had a million more questions, but-

Melissa Hansen:
Time is finite.

Mike:
Time-

Melissa Hansen:
Our time is finite anyways.

Mike:
Time like the hackathon isn’t on our side. But I think it’s really cool what you guys built, and I would love to see something like that come out. I think for people that have listened to the podcast and they’re like, “Oh, it’s a conference schedule thing.” Yeah, I don’t think we’d use that. Folks, it’s like meetings. If you’ve ever got two or three people, you got to schedule meetings for this thing, there’s so many relatable uses for it.

Melissa Hansen:
Yeah, absolutely. I can think of a lot of places where this would come in handy. And even, I think just learning it is such the case that once you get into it and see how it was built, then you start to see the other applications. It’s like, oh, but we could use this for managing our conference rooms or a whole variety of other things. Once you see the kinds of questions that can answer for you, given data that would take humans a long time to munch through and align.

Mike:
Yeah. And you only had a finite amount of data to work with as opposed to what an organization may have after even a few years.

Melissa Hansen:
Right. Yeah, there’s some rich data sets out there, which is great because yeah, we’re going to continue to develop this thing and hopefully have a useful tool that other members of the community can utilize. I’m thinking about taking it to the next community sprint, and seeing if we can get some more help and more use cases over there because such a cool, cool event.

Mike:
Yeah, everybody needs to share out those use cases. Let’s end on a high note. What’s one word your teammates would use to describe you?

Melissa Hansen:
It’s a hard question. Let’s go with analytical.

Mike:
Oh, I feel you were very analytical in coming up with that answer.

Melissa Hansen:
That’s fun.

Mike:
That’s great. Well, Melissa, thank you for being on the podcast. This is wonderful. I feel you’ve done a lot to inspire people to just sit down and be curious with an agent, and see what they can and can’t do, and just be creative with it.

Melissa Hansen:
Well, cool. Thank you so much for having me on, Mike. This was really fun.

Mike:
Big thanks to Melissa for joining us and sharing her thoughtful insights, not just on building with AI, but on collaborating across roles and using tech to empower others. If you enjoyed this conversation, share it with a fellow admin or developer. And don’t forget, you can always find more resources at admin.salesforce.com, including a transcript of today’s show. Be sure to connect with other Salesforce admins in the Trailblazer community. And as always, until next time, we’ll see you in the cloud.

The post Building With Agentforce and Flow: A Developer’s Hackathon Experience appeared first on Salesforce Admins.

  continue reading

330 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide

Listen to this show while you explore
Play