The Salesforce Admins Podcast is back atcha with Austin Guevara, Senior Platform Product Designer at Salesforce. We have a great conversation about how he goes about testing prototypes and getting user feedback.
Join us as we talk about how Flow Builder is designed, the importance of user feedback, and the value of accessibility in design.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Austin Guevara.
If you haven’t already, check out the Essential Habits for Salesforce Admins module on Trailhead. Become one of the first admins to get the new badge!
Austin is a product designer working on Flow Builder, which means he spends a lot of time “trying to understand the problems related to automation that our admins encounter. [I] think about how we can help them be more efficient, effective, and delighted when they’re doing what they do,” he says.
As a product designer, his job is to understand deeply what the user experience is like for admins, what challenges they face, and how they can help solve those problems. That means he has a lot of conversations with folks like myself to understand what things feel like right now and what other admins are saying. Product designers also spend a lot of time talking to everyday customers, getting feedback, and working through prototypes to figure out what will work best.
Austin spends a lot of time working with different types of mock-ups of the product he’s designing. Sometimes they’re built in HTML to rough out what the finished product will look like, sometimes (if they’re far along in the process) it’s something with a lot more bells and whistles, sometimes it’s as simple as a sketch on a piece of paper. What matters is getting the idea in front of people in a way they can understand and talk about.
This kind of process can be useful no matter what you’re building. Figure out the simplest way to get your ideas out there—usually, it’s pencil and paper—and then put them in front of someone to see if they make sense. “The best thing about creating a cheap prototype,” Austin says, “is that you didn’t put a ton of time into it. The goal is not to be the solution, the goal is to help get more information that will get you to a better solution.”
The important thing is to keep getting more information and keep iterating. “Admins are designers: they are designing solutions that end users are going to interact with one way or the other,” Austin says, “and what helps me as a product designer is realizing there’s no black and white about what is the best solution. But with more information and more craft you can create a better solution that most optimally addresses the problem you’re trying to solve.”
SABWA—Salesforce Administrating By Walking Around—is a key skill to get a sense of what’s working and what’s not. The important thing is to have a learner’s mindset. Observe what’s going on so you can learn how to make things better. One technique Austin suggests is to sit down with users and have them teach you how to do something in Salesforce. Ask them to talk through what they are doing and explain why they are doing it that way. This can help you understand the thought process behind their workflows and where you can give them a helping hand.
Austin has a lot more great advice about how to ask productive questions that don’t lead the responder, where to learn more, and why accessibility benefits everyone, so be sure to listen to the full episode to learn more.
J.:
Welcome to the Salesforce Admins Podcast, where we talk about product, community, and career to help you become an awesome admin. This week, we are talking with Austin Guevara, senior platform product designer at Salesforce about how Flow Builder is designed, the importance of user feedback and the value of accessibility in design. But before we jump into that, I have some exciting news.
J.:
Available now on Trailhead is a new module for the essential habits for admin success. That’s right, the webinar slash Trailhead live slash presentation, you have all loved and listened to is now a learning module on Trailhead. The link is in the show notes. So after this episode, head on over to the Trailhead and be one of the first admins to get the new Essential Habits Trailhead badge. Now let’s get Austin on the podcast.
J.:
Hello, you wonderful admins out there. I have a great guest here. Hi Austin. I am joined by Austin Guevara today, who is a senior product designer for the Salesforce platform. Austin, you and I have known each other for quite some. We’ve worked together pretty consistently during that time, but that is not true for everyone that’s listening out there. Could you introduce yourself to the awesome admins who are listening today? Tell them a little bit about who you are, what you do.
Austin Guevara:
Yes. I would love to. Hi admins. It’s great to be here. Thank you so much for having me, J.. Like you said, my name is Austin and I am a senior product designer. And the team that I work with is platform automation, which means that I am lucky enough to be a designer for Flow Builder.
Austin Guevara:
That is the majority of what spend most of my time thinking about and trying to understand the problems related to automation that our admins encounter, and think about how do we help them be more efficient, more effective, and just be more delighted when they’re doing what they do.
J.:
Yeah. Could you just describe to our listeners the way in which you and I work together?
Austin Guevara:
Yes, absolutely. So just a little bit. If you’re not familiar with, I guess, my title is product designer, you might also hear UX designer or user experienced designer used somewhat interchangeably. And what that means is that I work with our wonderful product managers and our engineers and our content experience folks. And my job is to understand deeply what is the experience, the current experience like for our customers.
Austin Guevara:
What are some of the challenges that they are facing and then think holistically about how do we go about solving that problem. That stems everywhere from what is the set of concepts that we present in Salesforce. But it also comes down to, all right, what do the actual, what do the things look like, what does it feel like to build a Flow for example.
Austin Guevara:
And so if we’re working on a new feature, and let’s say that that feature is related to how you manage your record triggered Flows, for example. And this is a real example because J. and I talked about this recently. In order to understand those problems in order to really empathize with what challenges people are encountering, I need to talk to people.
Austin Guevara:
And since I can’t actually live someone else’s experience, the only way to do that is to ask them questions and understand their experiences. So J., and I have talked many times about… Love to come to you as someone who is both experienced as an admin yourself, but also who knows and talks to a lot of other admins to understand what are the real-world challenges.
J.:
Yeah. To take a step back and kind of make this really explicitly clear to anyone who’s listening. If we take a look at Flow Builder for example, Flow Builder didn’t always look and feel the way that it looks and feels today. When I started as an admin, blushingly I have to confess it’s been about 10 years now, since I started using the Salesforce platform, we had what was called, I believe Cloud Flow Designer.
J.:
And even that was not the first iteration of Flow Builder. To my understanding this predates me. I believe that there was actually an application that you had to download and then you’d create a Flow and you’d upload that Flow. And then you could use the Flow on the platform.
J.:
I could be getting that wrong by the way, because again, that was not my personal experience. But if we take a look at the difference between the Cloud Flow Designer and Flow Builder, which we’re using today, the experience is pretty significantly different. The look of it. I like to call the older version Cloud Flow Designer, it felt very much like a program from the eighties, right?
Austin Guevara:
Mm-hmm (affirmative).
J.:
It was just, it was incredibly functional, lots of power behind it, but it didn’t look as though it was created with the experience of the user first and foremost in mind. Whereas, when we look at the current Flow Builder, it is much clearer today than it once was how to use it, what you can do with it, how you should interact with it.
J.:
And so anytime that you’re trying to modify that look and that feel, you go out and you talk to a number of people. And it just so happens, I’m one of the people internally at Salesforce that you speak with. But who are some other folks that you interact with on a regular basis or that your team would interact with on a regular basis to collect some more feedback, to understand how users interact.
J.:
Right? Because that difference between the two versions of Flow Builder that we’re talking about, that’s just an example, but it’s a really significant difference. And obviously, you didn’t make those choices or the team didn’t make those choices in a vacuum. So who do you approach? How do you approach them? How often do you approach them? What’s your relationship with the audience that is using the stuff that you make?
Austin Guevara:
Yeah. So there’s a number of different ways, depending on what point in time that we are going to try to talk to the real people using the thing and understand, all right, how do they go about using it. Of course, as wonderful it is to be able to talk to someone like you J., who is just a Slack message away and who we can spin up a video call at any point in time and just chat about something.
Austin Guevara:
We also really want to talk to customers, to people who are using Flow for their job every day. So there’s a few different ways that we might do that. We have a whole Salesforce user research recruiting team. So oftentimes they will actually go through the recruiting process for us. We’ll tell them, these are the types of people that we want to talk to because of the, whatever the feature is that we’re working on.
Austin Guevara:
And we will get users to be able to talk to that way. Sometimes we send out surveys to ask for feedback. Other times we will send out a self moderated test where you will click through a prototype and be able to like speak aloud about what you’re seeing. And in other times we might reach out directly to members in the MVP community who are very, very eager and excited to share their opinions.
J.:
Yeah, absolutely. You brought up prototype, which is something I’m really fond. The interaction that we have are great no matter how we’re interacting.
Austin Guevara:
Yeah.
J.:
I think you’re a very fun person, but I think the thing I enjoy most is when I actually have a prototype to click through, is we can have a conversation about it as we’re doing.
J.:
So can you talk a little bit about your prototype process and as you’re working with folks on the product side, and you’re developing a prototype, and that starts to become an interactive thing that people can touch and provide feedback on, what tools are you using and how rapidly are you designing?
J.:
How quickly do changes go from an idea, a conversation to product, into a prototype that you get feedback on and then ultimately get deployed. So kind of a few questions bundled together there, but go ahead and take a crack at them.
Austin Guevara:
All right. Yes. I mean, I love talking about prototyping because it’s one of my favorite things that I do. And that’s one of the reasons that I’m a designer is I love creating something that is sort of like a simulation of what the final thing is going to be, and then figuring out, using that as a way to have a clearer conversation with somebody or to just get a sense for yourself of how this thing is going to work.
Austin Guevara:
And the thing about prototypes, as a word prototype, I think you can describe so many different things. For me, and maybe the thing that comes to mind for you as well is something that looks a lot like the real thing, and maybe even as interactive and that you can click on and get a feel for how it actually works. But prototyping is really something that you use throughout the entire design process.
Austin Guevara:
And it doesn’t just have to be something that you would create in really what we call, high fidelity. In other words, looks really close to the final thing. So we do, we spend a lot of time in Figma, which is a design tool, which you can actually start using for free if you wanted to, if you wanted to play around with it. Or maybe even code and HTML, and that will create a really high fidelity prototype.
Austin Guevara:
But typically, if we’re doing that level of high fidelity prototype, it means we’re pretty far along in the process. And before we’ve created that prototype, we have many others that are of much quote, “Lower fidelity” that we’ve created first.
Austin Guevara:
So that could be everything from literally sketching with pencil on a paper, boxes and text that just kind of describes what we’re thinking about to maybe some wire frames. Literally think about like pulling up MS Paint or PowerPoint and drawing some boxes. But what I love about that is it’s as much as there’s this specific skillset of using these, of using HTML or higher fidelity tools, anybody can draw a picture on a paper as a way to help communicate with other people.
J.:
If I can interject here for just a second.
Austin Guevara:
Yes.
J.:
What I like about what I’m hearing, and what I think is particularly relevant or valuable for the admin community, is you a professional designer who makes UX changes and UI changes to a tool that is used by millions of customers around the world, you’re talking about getting a piece of paper and just sketching some stuff down or throwing some stuff together in PowerPoint or in MS Paint.
J.:
The reason that I like that you’re talking about this is I’m a huge fan of the design phase of any kind of Salesforce administration work. Right? Which means oftentimes when I’m advising folks in the Pathfinder program where I mentor or elsewhere, I’m often talking about closing the computer for a little while.
Austin Guevara:
Yeah.
J.:
And just going over to a whiteboard or opening up a journal or whatever you have in front of you, and really starting to kind of sketch out your ideas, whether that is the data model of the thing that you’re trying to build, whether it’s the screens that you’d like on a Flow, whether it’s the lightning page that you would like to have for a record and spend some time with that design first. And in fact, the thing that I’m kind of like a broken record with this. I’ll tell people to go and sketch your first idea, show it to someone, take all the feedback that they give you and then your first sketch away.
Austin Guevara:
Yeah.
J.:
Start a second sketch fresh from that feedback. Right?
Austin Guevara:
Yes.
J.:
And it sounds to my ears, Austin, that you’re talking about something very similar here, right? Where we don’t need something that is what you’re calling high fidelity, or for admins listening out there, I would just say, you don’t need something that’s incredibly fancy or complicated to convey the initial ideas of your design. And does that sound right to you?
Austin Guevara:
Yes. What I love about what you said there is that you have-. I guess, I think of sketching on paper as a really cheap way to get your ideas down. And I love what you said about take it to somebody, show it to them, get feedback and throw that away. Because the best thing about creating a cheap prototype or a cheap just design, quick way to get your ideas out is that you didn’t put a ton of time into it. And ultimately, the goal of it is not to be the solution in itself. The goal is to help you get more information that is going to help you get to a better solution. So yeah, that’s a great way of describing it.
J.:
Awesome. So we’ve got this idea of coming to a better solution, iterating, moving from a low fidelity to a high fidelity solution, prototyping. At what point in your process do you or your team members say, “Okay, I’m going to let this fly and let’s deploy.”
Austin Guevara:
Yeah. I mean, we try to work with the different roles that we collaborate with in a more agile fashion. Which means we try to avoid the typical waterfall approach of, “All right, I’m the designer. I’m going to come up with what the design looks like, and then I’m going to send it off to the engineers to go build.” Ideally, we are involving engineers throughout that entire process.
Austin Guevara:
Not only to be able to kind of check what we are trying to do technic, but also because they’re great ideators and they have a lot of wonderful ideas about how we can address problems. So we work closely with them. And I guess, to answer your question, sometimes it’s hard to say exactly when things are quote, “Done” because you kind of continue to work on them. And so we know that at Salesforce, we have our three releases a year.
Austin Guevara:
And so over each of those release periods, you can kind of think about each four month period as like a cycle. And so near the very beginning of that cycle is when we are more open-endedly trying to think about what is the specific problem that we’re trying to solve. And that’s when we’re going through with our sketches and trying to get our ideas out there and try to refine to a more specific, this is the feature that we are trying to address.
Austin Guevara:
So then over the course of, let’s say a six weeks, we’re refining down to a more specific, “Here’s the designs. Here’s what this feature could look like.” Maybe a prototype that shows like this is what the interaction will look like. And then at that point, we are working with engineers then to break that down to figure out, all right, how much effort is this going to take.
Austin Guevara:
How much is it going to take to develop this? And then we’re working with them side by side as they are working on that, to help answer questions as they come up. So that kind of answered your question, that kind of didn’t. There’s no real end. Because the other thing is even after the release goes out, there’s very few things or very few features that I’ve worked on where it goes out and then we’re done with it. It’s typically something that we’re continuously evolving.
J.:
Let me ask-. Actually I want to interject on that because.
Austin Guevara:
Yes.
J.:
It’s a question that I’ve had that I’ve been interested in across all of our products. And I don’t think I’ve ever actually really asked the question. You said that most things aren’t ever finished, you’re always tweaking and enhancing them, has there ever been anything that you’ve been working on where it’s just been, “Okay, yes, that’s done. Let’s step away. And let’s focus all of our efforts on something else.”
Austin Guevara:
It does happen sometimes. I would say at some point we’ve all experienced this. There’s some products where we say, “Hey, there’s something new that we believe is going to be the better way to address this problem area going forward.” And so at that point, oftentimes that means, hey, this thing that we’ve iterated on this product we’ve iterated on for multiple years, we’re not going to invest new effort in because we’re putting all that new innovation into another area.
J.:
Yeah. So what I’m hearing is outside of things that end up kind of being sunset or going end of life, or we announce another product that may be the future of that same kind of functionality, we really keep tweaking until we decide, all right, cool. There’s a better way to do this. Let’s put our efforts over there.
Austin Guevara:
Yeah. I think what’s interesting about design and something that I’ve come to terms with the more time I’ve spent in my career is that there is no such thing as a perfect solution. And so I’m sure that, I mean, I would say the admins are designers, right? They are designing solutions that your end user are going to interact with one way or the other.
Austin Guevara:
And I, as a product designer, often try to… Am stuck in this mindset of, “Oh, I’ve got to find the right answer, the right way to do this.” And what helps me sometimes is realizing there’s no yes, there’s no black and white about this is the best solution. But with more information and more craft, you can create a better solution that most optimally addresses the problem that you’re trying to solve. So that, I think if you think about things that you keep iterating on, that’s why, because we keep finding ways to improve things.
J.:
I am really glad that you mentioned that because one of the things that we really try and focus on with our admins, there are a lot of skills that we talk about is the Salesforce admins. There’s a bucket of skills that we think are really, really important. There are core responsibilities that you have as a Salesforce admin that correlate to those skills.
J.:
But one of the things that we really emphasize in the audience relations team or the admin evangelism team is continuously going back to your users, riding side by side with them, or visiting them where they’re working and kind of understand their day to day, observing them, seeing how they interact with the applications that you’ve configured or developed on the platform. And then basically take notes, right? A lot of the recommendations that we make, as we’re talking with admins that are out there in the awesome admin community, we talk about you don’t have to ask any leading questions.
J.:
If you just sit next to somebody and you witness how they’re interacting with the thing that you’ve put together, if you’ve got a learner’s mindset very often, you’ll start to observe things that need to be tweaked. And need might be the wrong word, maybe it’s things that could be tweaked, right? Are we able to eliminate a click? Are we able to highlight or bring into focus, something on the screen that has been previously overlooked?
J.:
And it sounds to me like we’re kind of saying the same thing there. And I really enjoy that because I agree with you. Not only do we have a new certification for user experience, design, but I think that we’ve been doing this as admins for a very long time from page layouts to record pages to the way that we even assemble a report or a list view, the way that these things look and feel. Even if they’re within a certain visual vocabulary, they still have impact.
J.:
And the choices that we make are never really finished. And I’ve found in my experience as an admin, that it was very similar, right? I’d have a release schedule, maybe once a month, we would have things that we were collecting from the business that needed to be implemented. But we’d also be thinking about those things that they needed a little bit more attention and Finesse because people are using them every day and they’re observing things that cause them friction or cause them displeasure.
Austin Guevara:
Yes. There’s plenty of that. And I guess, I have a few thoughts or words of advice. I love the, going to where people are using the thing and observing them using it is one of the best ways you could possibly learn about how to make things better.
Austin Guevara:
And something else you might try that is similar to that is you can sit down with them and say, “Pretend like you are teaching me how to do this.”
J.:
Yeah.
Austin Guevara:
“And just speak out loud through what are you doing and why are you doing it? And I might jump in with questions to ask why you’re doing something.” That way you cannot only see how they’re doing it, but also understand their thought process behind it.
J.:
Well, would you agree as you’re doing that, that it’s important to just focus your questions around the purpose of the action that the user is taking without trying to lead them to a solution that you think is the most appropriate?
Austin Guevara:
Absolutely. But that’s definitely one of the biggest skills related to, I guess, doing user research. That definitely takes some practice. But as much as possible, not structuring leading questions. For example, instead of asking, “Why was that difficult for you?”
Austin Guevara:
Right? You might ask something like, “How would you describe your experience with that?”
J.:
Right.
Austin Guevara:
So thinking about the neutral language that doesn’t lead them to, oh, something that is definitely negative or something that is positive, but just, “How did you experience that?”
J.:
Yeah. So on that note, right? What I’m hearing is if I ask somebody, “How difficult did you find that?” What’s being emphasized, there is difficulty. And in fact, the way that the question is structured, there is no room to give an alternate answer within the confines of the question, right?
J.:
I have to tell you how difficult something was. I can tell you that it wasn’t very difficult, but you’re still getting a difficulty answer as opposed to, “How would you describe that experience?”
Austin Guevara:
Right.
J.:
I am now free to use difficult, I can use easy. I could use other words that the designer may not have thought of at.
Austin Guevara:
That is absolutely true. And something else, anytime I’m opening up a conversation, either an interview or contextual sort of study where I’m watching somebody as they do something, I always try to cue them with, “Tell me you’re very honest and open feedback? There’s no hard feelings here. I’m not testing you. Whatever you have to say is valuable.”
Austin Guevara:
Because I think people tend to sometimes be overly nice. They might soften their actual experience because we work with a lot of, which is great, but sometimes what you really need is the honesty. And to be able to take that. And not take it personally, but just see it as an opportunity to make the thing that you are working on even better is will take you really far.
J.:
I’d say also in my experience as I’m going through that same encouraging folks to be as honest about their experience as possible, I have found in my own personal life, sometimes I also have to remind myself to take what folks are saying with some grace, right?
Austin Guevara:
Yeah.
J.:
Because as you are working with users, even a passing comment, “Ah, I hate this page,” right?
Austin Guevara:
Yeah.
J.:
Or, “Whenever I try and save this, it sucks.” Right?
Austin Guevara:
Yeah.
J.:
That kind of language, if you’re not prepared for it, or if you don’t remind yourself in advance, if you’re a person like I am, I am a sensitive flower and my feelings will get hurt unless I remind myself, hey, they aren’t directing this toward your value as a designer or your value as an admin.
J.:
Instead, this is just honestly how they feel about the thing that’s in front of them. And I find myself having to armor up a little bit it sometimes and saying, “It’s going to be cool. Even if it’s bad, it’s going to be cool.” Because that’s going to give you the feedback you need to make it better for everyone.
Austin Guevara:
Yeah, absolutely. I think it’s really just sort of a mental shift. If you can position your minds that what I am getting here is data. I am collecting data. It’s not a personal attack on my abilities or the thing that created.
J.:
I love that. So we’re nearing the end here. I would like to know from you, Austin.
Austin Guevara:
Yes.
J.:
What do you think are admins out there, what nugget should they take away from you, a designer about their day to day work? Is there any last word of an advice, skills that they should pay attention to, resources that you enjoy? It’s a broad bucket. You can fill it the way that you want. What’s the wisdom that you pass on here at the end of our conversation?
Austin Guevara:
There are so many things I could say, but there are a few things that come to mind. If you are interested in learning more about the topic of human centered design, which really can be implied in so many areas. There’s a book called, The Design of Everyday Things, which is a great resource that is sort of the Bible on understanding that whole way of thinking about, of creating things. There is also the Salesforce UX designers certification. And of course, a company with that is an incredible trail mix that has a ton of resources that of course are very Salesforce specific. So I think-.
J.:
Which we will link to in the blog post associated with this podcast.
Austin Guevara:
Go click it now and explore it. Yeah. And also, I was going to share, there is a talk from I believe is a Trailhead DX from a couple years ago from one of my colleagues that is basically applying the design thinking process to creating a homepage.
J.:
Oh.
Austin Guevara:
And so it’s not for Flow specifically, even though I like to, I’m kind of biased towards thinking about things related to Flow, but it’s a great way of, hey, how might I take some of these concepts and apply it to something that I am working on in the near future.
J.:
Awesome. I’ve got one last question that I want to ask you.
Austin Guevara:
Yes.
J.:
Because I want to end it just on a tone of controversy.
Austin Guevara:
Oh good.
J.:
Do you prefer Freeform or Autolayout?
Austin Guevara:
Oh, this is a great question. I’m so glad that you asked. If I’m going to pick something, I would have to pick Autolayout. And let me explain.
J.:
Wow.
Austin Guevara:
Let me explain a little bit. So Autolayout is something that the Flow team has worked on not only as what it might appear initially, which is to take my Flow, organize it nicely, not make me think about how I’m connecting things, which is a great advantage, but it also is pretty powerful for keyboard and screen users, because now they have a procedural way to navigate through an entire Flow and understand how things are ordered and create things in a logical way.
Austin Guevara:
That’s one of the reasons I love Autolayout so much. And also because there’s a lot of more love that we are giving to Autolayout. We said that things are always iterating. There’s more to be added to what Autolayout has to offer. So yeah, I’m very excited about some of that stuff that we are working on, but I hope you can see why Autolayout’s so great.
J.:
My preference for a long time has been Freeform, but in talking with you today, I’ve learned that the accessibility features of Autolayout are really cool. And I’ve seen, I follow a lot of designers on Twitter, I’ve seen a lot of conversations around accessibility, especially recently.
Austin Guevara:
Yeah.
J.:
And I’m newer to that space, so I can’t put my finger exactly on why. It may have been a conversation that’s been happening for a very long time. But I love the fact that it’s something that you are taking into account as the designer. I’ve actually worked at organizations in the past where some of the Salesforce developers that I’ve worked with have been vision impaired. And they were using screen readers all of the time to write their or code and interact with things, which is pretty fantastic.
Austin Guevara:
Yeah. What I love is that it’s, when you focus on creating an experience that is inclusive and that is a great experience for everyone, for example, for those who are reliant on a screen reader to do most of their work, you end up creating something that’s great for every one and even better than it would’ve been otherwise. So I love taking that lens anytime I’m approaching a design problem.
J.:
That is the end. That’s the note we’re going to end on. Austin Guevara, senior product designer for Flow Builder. Thank you so much for joining us today. Admins, this has been a blast. And beware Austin, just as you come calling for me sometime, I may call you again and ask you to join me for a conversation here on the Admins podcast.
Austin Guevara:
Thanks, J..
J.:
If you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find more resources, including all the links we mentioned in this episode, as well as a full transcript. You can say up to date with us on social. We are at Salesforce admins no I on Twitter. J. is at J. underscore, underscore MDT. Austin is at Austin Guevara. Stay safe, stay awesome, and stay tuned for the next episode. We’ll see you in the cloud.
Today on the Salesforce Admins Podcast, we talk to Andrew Russo, Salesforce Architect at BACA Systems. Join us as we chat about Salesforce Foundations and why it’s a game changer for solo admins and small orgs. You should subscribe for the full episode, but here are a few takeaways from our conversation with Andrew Russo. […]
Today on the Salesforce Admins Podcast, we talk to Eddie Cliff, VP of Product Management at Salesforce. Join us as we chat about Salesforce Foundations and how it can give you access to even more capabilities within Sales, Service, and beyond. You should subscribe for the full episode, but here are a few takeaways from […]
Today on the Salesforce Admins Podcast, we talk to Lisa Tulchin, Senior Curriculum Developer at Salesforce. Join us as we chat about user learning styles and how to use them to create better training sessions. You should subscribe for the full episode, but here are a few takeaways from our conversation with Lisa Tulchin. Choose […]
