Today on the Salesforce Admins Podcast, we talk to Alastair Dinning, Senior Solution Architect at Salesforce.
Join us as we chat about the process of adding new features to your org, from what to look for when you’re reading through release notes to rolling something new out and driving adoption.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Alastair Dinning.
The exciting thing about working in the Salesforce ecosystem is that it’s continually evolving. A new release is always around the corner, chock-full of new features that could improve your org. But how do you sift through everything to figure out what will add value and what’s just a shiny new toy?
My guest this week is Alastair Dinning, a Senior Solution Architect with Salesforce Professional Services. He has 14 years of experience as a consultant for businesses of all sizes, helping admins change their orgs for the better.
For Alastair, the most important thing when you’re looking through release notes is to have a clear understanding of your business processes and problems. Do any of these new features address a pain point? Whether you practice SABWA, run a steering committee of power users, or use a case management system for feedback, you need to have your finger on the pulse of your users.
Once you’ve identified a problem you’d like to address, Alastair lays out three options: you can build a declarative solution yourself, you can buy a solution off of the AppExchange, or you can work with a developer to code something custom.
Building your own declarative solution means that you end up with something that’s tailored exactly to your specific business requirements, but it also costs you resources in terms of time.
Buying something off the AppExchange, on the other hand, costs you money up front, but you’re saving a lot of time and can deploy the change quite quickly. Even if the solution isn’t 100% right for your specific problem, Alastair encourages you to reach out to the AppExchange partner because they’re often willing to make improvements.
Finally, coding a custom solution is probably the most expensive in terms of internal resources, but gets you exactly what you want. The drawback here is flexibility. You don’t want to end up with a solution that you can’t update if your business context changes in the future.
If you’ve spent time with your users and really understand their pain points, adoption should come easily. But at the end of the day, the job of the admin isn’t to constantly roll out new features—it’s to make life easier for your users.
Sometimes, the best thing you can do is to keep your Salesforce environment consistent and stable. That means not only identifying which new features could possibly be helpful for your org, but having proactive conversations with leadership about the bigger picture.
Make sure to listen to my full conversation with Alastair for more about how to roll out new features to your org and how admins can best work with consultants. And remember to subscribe to the Salesforce Admins Podcast so you never miss an episode.
Mike:
This week on the Salesforce Admins Podcast, I’m talking with Alastair Dinning, a senior solution architect with Salesforce Professional Services about how admins can decide if a feature is right for their org. We’re going to dig into how to spot the business problem behind a feature, when to click, buy, or code your solution, how to prototype before making a big investment, and why timing and support ability matter just as much as functionality. So next time you find yourself reading the release notes and thinking, “Oh, that looks cool,” you’ll have a framework for deciding when to implement it. With that, let’s get Alastair on the podcast. So Alistair, welcome to the podcast.
Alistair Dinning:
Thank you, Mike. It’s good to be here.
Mike:
We connected ironically over Slack. Not ironic. Is it ironic? I always get hung up because I’m afraid I say ironic because I learned irony from Alanis Morissette, but we connected over Slack because you’re a fan of the podcast and you work at Salesforce. And I was like, “Hey, I have this topic that I think you’re perfect for.” So let’s start off by you letting everybody know what you do at Salesforce and how you got there.
Alistair Dinning:
So I am a senior solution architect with Salesforce Professional Services. I’ve been at Salesforce for give or take five years. I’ve been working in the ecosystem for 13 and my entire career has been as a declarative consultant and into being in the architect world. And I came to Salesforce through the acquisition attraction on demand and having spent my whole career, my Salesforce career in Salesforce consulting. So I’ve worked with a good number of organizations, whether they be small business, medium business, large business, government. I’m working currently with the Canadian federal government. I’ve worked with education, with nonprofit. And I mean, as a consultant, that’s my approach to this job. And it’s like, how do we as admins do things declaratively and do things well? And what can we bring to the table?
Mike:
Yeah. Wow. Worked with government. You must have a lot of scissors to cut all the red tape.
Alistair Dinning:
Yeah, government does bring a lot of red tape with it, but you make sense when you’re talking about taxpayers’ money.
Mike:
Yeah, no. I mean, it’s all intentional for a reason. So let’s talk… One of the biggest questions I always get, and it’s a question I had as a Salesforce admin, which is how do I decide if this feature is right for my org? And feature could be anywhere from the biggest feature do we flip on? At one time we had customers had a choice of turning on lightning all the way down to the smallest little checkbox that maybe we added. And I was reading through some of the stuff that you do at Salesforce and I thought it’d be great to have that conversation with you about helping admins figure out if a feature is right and maybe give them some of your thought process into that. So I think that’s where we’ll start.
Alistair Dinning:
Absolutely. So one of the fun things about Salesforce that I’ve always appreciated is the three releases a year and the fact that we get new functionality every four months or so, and there’s always something that’s in those release notes that’s exciting. And again, the advantage of having been a consultant is I’ve seen all of these different organizations and I see these new tools coming from the release notes and I’m like, “Oh, that’s cool. That’s really fun, and I think that’s going to add value.”
But to your question, is it just this shiny new toy or is it actually going to add some real value into the solution? I think I always start with, “Okay, so that looks cool, but how is the business going to utilize it?” From two points, either is there a business value that we can add with this new feature or is there a pain point that I as an admin have seen, I’ve heard from my users time and time and time again where they’re all like, “I don’t like this. I don’t like this. This is a slow process. This is in my way,” boom, boom, boom. And does this new feature address that pain point?
So if I was to take Dynamic orms in the Lightning Page Builder, they’re super cool because we could do all sorts of fun things with it. But it’s only useful if, for example, the business say to me, “Hey, my page layout is completely cluttered with all this stuff that I don’t use at the beginning of a opportunity process. So why do I have deep fields on or a whole ton of fields on opportunity development when really we’re just trying to identify what the opportunity value might be, value prop might be for this customer?”
Mike:
I think that’s a great start. And I know I thought of that. I’ll say this, I would really love it if the business was as explicit as you say they are like, “Oh, there’s really this problem with too many fields.” I think oftentimes you have to peel back a layer and listen to users say, “I’m just struggling to find the right information on this page.” Or I remember when I was an admin, we brought on a different business unit and I remember the business unit asking why there was this entire section of the account page and it was kind of in the middle and it was above all of the information that they needed. And I said, “Well, if you don’t like it, you can just collapse that section.” And they said, “Yeah, but shouldn’t it know whether or not it should show that to me?” And this was before Dynamic Pages.
And so I bring that up to say, I hear you. I wish it was that explicit, but sometimes you almost have to listen and put two and two together for them.
Alistair Dinning:
That’s right. It can be hard for the business to know how to articulate what they want from the solution. But as an admin, there are a couple of tools you’ve got. One is you could spend some time desk side with your key users or have a steering committee of users who are giving you feedback on a regular basis on what they’re using, what they like, what they don’t like. The other option is that if you have an ITSM light solution where you’ve got case management, so your users are providing functionality cases or technical cases on Salesforce, on their usage of Salesforce, then you can actually scroll through the data and see what people are saying, “This works for me. This doesn’t work for me.” And I mean, if all the cases are coming around a particular topic, then you know that there’s a problem there and that’s got to go in your admin backlog of things to address in due accord.
Mike:
Yeah. And I think you mentioned the three releases a year. Obviously we’re always working to solve issues that enough customers have brought up, maybe not specifically in your case, but somebody has that issue. That feature didn’t just get born out of a wishlist. It got born out of somebody really had that pain. I also think you bring up an interesting point of, so when you’re looking at, should I just implement this feature? Is it actually solving a real problem or do I have to invent the problem or is there a better way to solve that problem?
Alistair Dinning:
So when we come to, is there a better way to solve that problem, there’s a three step process that I’ve always applied to implementing functionality in Salesforce. And there’s two steps to this process. One is those, are we going to click it? Are we going to buy it? Are we going to code it? In terms of solving the problem for the business requirements? We’ve identified a business requirement. We’ve said, “We need to fix it.” Can I declaratively solve this problem? Can I just build it out of the box with the tools that come? And I mean, I’m a declarative consultant. I don’t write code. So could I do it? Can I build a piece of functionality that’s going to allow me to do that? Do I want to buy it or do I want to install it? So do I want to go to the AppExchange and pull something from the AppExchange that’s going to solve the problem because this is a problem, to your point, this is a problem that multiple people have had.
And so somebody else already went and built the solution and put it on the AppExchange. So we already know that those requirements exist. We already know that the solution exists and somebody’s taken the onus of really digging through that solution and thinking through the problems and debugging the solution, whether they’ve built a very comprehensive declarative solution or they’ve coded a solution and they’ve put it on the AppExchange and just made everybody else’s life easier. And sure, do you have to pay for that product? Most of the time, yes. But does that take away from you having to invest in development time? Also, yes. So paying somebody for a solution off the shelf can be a lot easier than coding it, but then coding it is our third option.
So you’ve looked at the declarative solution, you’ve gone, “This isn’t quite going to solve the problem the business has brought to me.” You’ve looked at the AppExchange and there’s nothing quite there that’s going to fit the bill. Again, this isn’t solving the problem the business bought to me. So then yes, then you’re into the point where you want to code a solution and work with your developers, work maybe with your UX team, work with your testing team on actually coding out a comprehensive solution to solve the problem, solve that business requirement that was there in the first place. But that’s a heavy investment.
So the flip side to that is that if you were to declaratively build it, can you get 80% of the way to the business requirement, whereas a coded solution would get you 100% of the way there? If you declaratively build it and you get 80% of the way there, what you also get is a lot of feedback from the business before you make a big investment in coding a solution. And that accelerates your development path, gives you a lot of feedback into what your coded solution might look like, but it does help you mitigate the cost and stop you going down the wrong path because your view as an admin as to what the business is after versus their feedback when they start road testing something in production is going to be two different things.
So either declarative and be done with it or declarative and use that as the prototype to inform your development path, again, assuming there was nothing on the AppExchange that met that requirement.
Mike:
Right. Or a hybrid of the two. I know there’s some AppExchange apps that you can even add on to.
Alistair Dinning:
Oh, yeah.
Mike:
And that would help out. I think that you bring up a good point and it’s one I never brought up when I was an admin, but not everything on the AppExchange is free. There’s a cost to it, but the cost would be ongoing as opposed to massive upfront that they would spend on you and it’s a small monthly fee. And you also benefit from, then they get time to upgrade it. Whereas if you’ve built something, who knows if you’re going to have time to upgrade it.
Alistair Dinning:
All of the above is true. The other thing with the AppExchange, which has blown my socks off in such a good way in some occasions, is that I found a product on the AppExchange that met 85%, 90% of my business requirements, presented it to the business, the business, “It would be nice if… I really needed to do X plus.” And I’ve actually been able to go back to the AppExchange partner, have a conversation with them because some of these… These are not giant software houses that are difficult to talk to. Some of these are very small independent consulting shops or software development shops and they will take your feedback and they’ll go, “Oh, that’s a good idea. That’s not on my product roadmap,” or, “That is on my product roadmap. Let me accelerate it.” Or, “Let me bring that into my roadmap and we will bring it to you as part of the product.” And they will actually take that feedback if you ask.
And I think the important thing to consider there is don’t assume that what’s in the app exchange is locked and finite and immutable, but it could be a discussion. And they will take that feedback because they want their product out there as much as anybody else does.
Mike:
Yeah. And if it’s a feature you’re requesting, who’s to say it’s not a feature that a lot more of their customers aren’t requesting? I like that. One thing I wonder in your day-to-day, because you have a really cool title of senior solution architect, how much, when you sit down with an organization or you sit down with an admin and the people that use Salesforce, how much do you talk to them about the amount of change that’s going on outside of just implementing Salesforce?
Alistair Dinning:
It can be some very extensive discussions because when I get pulled in to work with a customer, we’re typically doing a technology overhaul or a migration from a legacy platform into Salesforce. So there’s a lot of business process change that has to happen to make sure that Salesforce meets those requirements, but also make sure that the business users understand that Salesforce is going to support them and how Salesforce is going to support them. And these requirements will… The method of working can change quite drastically, even if the end goal is the same. The process of spending time and training people and understanding what motivating them before you actually even get into making any development change is really important.
So I try and step out of the weeds of, I need a form that asks X, Y, Z and fields, but what are we trying to achieve with this form? What are we trying to achieve with this business process? Or maybe even what is the metric that the business users are being evaluated on or being comped on? Because if you understand how people are being evaluated or how people are being compensated, that will drive and you can build a platform that will support those behaviors that will drive adoption and that will bring people into your world or into your process.
Mike:
The second you talk money, that’s when it becomes real for people, especially compensation. For every time I’ve rolled out a sales process, the salespeople want to know if X, when, Y, what’s my pay? Because A, that’s why we work, but also I want to make sure that I’m doing things right. And the reason I ask that is for the longest time as an admin, if I was pushing out new features, I felt I was doing my job. If I was constantly giving, and not constantly, not every day, but on a regular basis, if I was giving my users new features, I felt like I was doing my job. And it didn’t really dawn on me until one of the organizations I was working at went through a massive leadership change. And here I am pushing out new features on opportunities for salespeople and stuff across the board, and everyone else is kind of grappling with also massive organization changes.
And I remember I sat back for at least two months and just didn’t push anything new because if I could control that environment and give my users a sense of normalcy when the rest of the organization is changing, then I wasn’t contributing to their stress.
Alistair Dinning:
That’s a very reasonable way of moving things forward and allowing the team to stay on an even keel.
Mike:
Well, I mean, part of, I think, understanding and thinking through is this feature right, is, is this feature right right now? Or would it be more right later given where everything’s at? The last thing, the cliche of that is you don’t want to push something new the last two weeks of a quarter because you’re radically changing a possible sales process or something that could affect books and numbers. So obviously that seems to make sense, but the same also holds true for other parts of the year when other parts of the organization are maybe going through a different change.
Alistair Dinning:
And this taps onto another point, which has just occurred to me. So yes, absolutely. When we are making changes in the Salesforce platform, we’ve got to be organizationally aware to, for example, to your point, where salespeople are in their sales cycle. Are we at the end of the month? Are we at the end of the quarter? Is this the end of the fiscal? I mean, everything should be end of fiscal. Big sales organizations that I’ve worked with or worked at, you don’t make any changes in the last month of the fiscal because the sales people are always focused on a single task and that is getting to their number. And we’re talking about salespeople, but it could be any other organizational goal and team where you need stability because there is a bigger goal to move to.
The second thought, when we look at how do we implement major change or how do we bring new product forward, it’s being organizationally aware in terms of understanding where the business is going and having conversations with leadership about, “Hey, we’ve got these brand new features, but are they going to be relevant in six months? If we look at a new quoting system to bring in new products, are we still going to be selling this line of product or do we need this level of complexity? Is this still going to be a thing? Is this worth the investment in the time and the change and the development if this doesn’t line up with the strategic objectives of the business?”
So being organizationally aware to what your changes are doing, how your business users are in their, not their life cycle, but their business cycle and where the business is going. These are all important points when we look at how do we bring new functionality forward.
Mike:
Yep. You talked in the future and roadmap and boy, every release, every time we have a major event, there’s always roadmap sessions, people want to look ahead. I know for a few times there’s been times where I’ve looked at a feature and thought, “Oh, I really want to implement it now, but if I just wait three months, they’re going to have this functionality and it’s going to be a lot easier for me.” And I think knowing that and being able to have your organization on pause to say, “No, let’s let the future mature,” then we’ll be ready for it as well, as opposed to implementing it too early.
One of the things I think we’re thinking about is taking that inventory of your own skill and thinking, “Once I implement this, is this something I can support?” And as somebody that helps architect solutions, at what point do you think through how much features can be deployed versus if a customer organization just doesn’t have the people power to support it?
Alistair Dinning:
So having been a consultant for 13 years, 14 years, whatever it is now-
Mike:
Your consulting is a teenager right now.
Alistair Dinning:
Basically, yes. Having been a consultant for quite a while, I’ve worked with a lot of small organizations and one of the things I’ve learned in that process is you can build, as an architect, I can design and build a really fancy whizbang solution that’ll really knock the socks off the business users, but for that thing to have legs, for that thing to have durability down the road, I need to trust that the admin team in the organization that I’m working with can keep it going. I’ve always kept an open door to any admin I’ve worked with, but at the end of the day, as a consultant, I’m in there for a period of time and then I do my job, I deliver my functionality and I leave. And it’s always the bit about my job that I like and I don’t like. I get to work with lots of great companies, but I also don’t see where things go six, 12, 18 months down the road.
So it is a concern that we make sure that the admin team, the development team have enough handover and enough technical capability to maintain any solution we deliver because we don’t want them looking at this in six months time or 12 months time thinking, “Oh my God, this was great at the time, but they didn’t know…” I mean, nobody’s got a crystal ball when you build functionality. You don’t know where companies are going, you don’t know what’s going to happen in the market, you don’t know how product’s going to get adopted and unpacked by your business users. So things have to be built scalably and things have to be built with the intent that somebody can maintain and continue to use it going forward. Because if it’s too complex, the admins that, as a consultant, that I’ve left behind are going to be cursing my name down the road.
They’ll be like, “What did he build me? This worked to begin with, but now I need to make some change. I don’t understand how I expand on this.” And so I’m really conscious of making sure two things. One is that the solutions I build are scalable, but two is that I have empowered the team that I’m working with, the client team, the admin team, that they have the tools to carry that product forward and they have the documentation to carry that product forward and they don’t inherit a bunch of tech debt and that they’re in a good place where they can understand it and debug it and enhance it and move it forward as their business dictates.
Mike:
So let me ask you this, because I think it’s very poignant. As having been a consultant and done that for a while-
Alistair Dinning:
A while.
Mike:
… what are questions that you really wish the Salesforce admin had asked you across the table?
Alistair Dinning:
I think it’s about understanding what the Salesforce admin skillset is and what their background is and what their appetite to learning Salesforce is. Actually, sometimes the other thing to know, and it’s not directly answering your question, but what I look for in that relationship with the admin is to understand their skills, their capabilities, their bandwidth for Salesforce, because in some smaller organizations, the Salesforce admin is not just the Salesforce admin, they’re doing other things too. They may be an operational support person, they may be a financial support person, they may be a sales admin type individual on top of having to learn Salesforce.
So again, it’s making sure that they’ve got the tool sets and that we’ve had a conversation about, “Hey, are you understanding that this is how this is built? Do you have access to resources? Do you have access to a local user group, a local admin user group to help you get support? What are the other resources and tools that you’ve got that we can make sure that you are good to go with this product once it’s gone? Do you understand how it’s built? Do you have the documentation? Do you understand the designs? Do you have this in a sandbox? Have you unpacked it in a sandbox or maybe a POC environment where you can really play with this thing without breaking what’s in prod?
Mike:
That’s really good. I mean, I think back to the consultants I’ve worked with and the really good ones, part of their pitch for that solution was, “And here’s how you configure it as an admin.” One of them was just a matter of changing some static resources and then you didn’t have to touch code.
Alistair Dinning:
Yeah. So static resources, custom metadata, custom labels, these are really important tools because you make all of the scalability of that buried, not buried, available to the admin in simple tool sets, which to your point, you don’t have to touch code, you don’t have to go and unpack a flow and rewrite business logic in a flow. You don’t want to be doing that.
Mike:
Talk to me about, have you ever had an inside group of a handful of users that was your internal champions that maybe when you were looking to roll a feature out, you would beta test it on them?
Alistair Dinning:
Absolutely. So the best example I can think of this is a university in Ontario where I was working with the business school. And that school we had Salesforce was being used by the professional services team, the student services team, the marketing team, the alumni group. I’m going to say there were two other groups there as well. I’m trying to think of all the different departments.
Mike:
Wow.
Alistair Dinning:
This business school had a COE, a Center of Excellence for Salesforce that was represented by business users from all of those individual departments and the IT group were there. They were there to answer the question that we were answering today, which was, “Hey, there’s this brand new feature in Salesforce. Do you want it? This is what it could look like. This is what we’ve heard from your users, but does this make sense to you?” And this school had a, they met on a regular basis. I would say every two weeks the COE would meet. And again, it was driven by business users who demonstrated an interest in both learning Salesforce and expanding Salesforce and contributing to the overall picture that we had one record of a student that we could follow their life cycle through.
So we had good transparency on what the motivation behind Salesforce was in this organization. And they had a forum where the business users could come with problems, the business users could come with ideas, and the IT group and myself as the consultant were there to say, “Yeah, Salesforce can support that and this is how we could look at it.” Or, “Salesforce can support that. Give us a couple of weeks. Let’s have some detailed conversations, then we’ll come back and see how this fits into the big picture.”
So having in any organization that we had, I think 120 Salesforce users in this group, this school, having a team of business users that would come together in a well-structured discussion forum where people were learning the product and able to contribute was really, really valuable for the development part of that because it wasn’t one executive who just determined that this is the way we’re going. It was the business who said, “This is the way we’re going.” Because the business asked for it, the business adopted it, because the business adopted it, they got really deep into owning the solution and they had true ownership of what that environment was and where that product was going.
Mike:
Wow. I’ve ran into something similar where the contract group of an organization really, really had a defined vision on what they wanted. And I created the demo and pushed it to them. And once it went live, they were the biggest champions because they were so invested in that feature. And it made the old system they were moving from just light years worth of antiquated. And it was kind of cool because then they could be at the forefront to help push change for other parts of the organization that maybe were a little less innovative.
Alistair Dinning:
Well, it’s not just less innovative. It’s maybe scared in some respects or unsure. I mean, I think when you have multiple groups working in Salesforce and you’ve got somebody who can really demonstrate the value and say, “Right, we can move an application from potential students signing in to application submission and review process. And we can drop the timeline that was that process that was four months. We can drop it to two and a half months because we were able to take time out here and take time out here because we can make the process more rigorous and more efficient and more locked down.”
If one team can show the rest of the business that, that’s far more valuable than myself as a consultant saying, “I can save you money. I can save you time.” It’s far more valuable than the admin even saying, “I can save you money and I can save you time.” Because if the business will step up and say, “Hey, we did cut costs,” or, “We did improve our opportunity close,” or, “We did cut our service response time,” then those are the wins that really matter that other business users hear and then get incentive to go, “Right, well tell me more. Tell me how did you achieve that efficiency? What did you do? Who did you partner with? What did they bring to the table?”
Mike:
Yep. I hear you. Thinking about timing of this podcast as it comes out, we’re right on the heels of the newest winter release. For an admin listening to this that’s reading the title very literally, How Do I Decide If a New Feature Belongs In My Org? Is there a thinking structure or I don’t know, a plan at which you go through release notes that you could give them as a way to think about how they look at features they see in the newest releases?
Alistair Dinning:
So I think the first thing to do is to marry up, “Hey, that looks fabulous in the release notes,” to where does that align to the business requirements that we’re hearing or the business problems that I’m hearing from my users? So if we have something that looks cool and we know it’s going to resonate, that’s the place where we start. If we’ve got 10… and there are hundreds of features in every release. But if you’ve got 10 things that catch your eye, which of those 10 things resonate against what the business has been asking for or complaining about? Because we can deliver what they’re asking for, you can fix a problem, that’s a great place to be.
Then we’re going to look to see how do we pilot that? We’re going to look at how do I get this in front of the business in a way that I can, for low investment, how can I build a proof of concept that the business can see and see whether it actually resonates and does this solve the problem? So whether this is building it out in the sandbox and turning on all its features, is this going to developer.salesforce.com/freetrials and grabbing a free trial that’s pre-built with this feature enabled because the developer of free trials, you have two choices. You can get an empty org or you can get an org that’s pre-populated with data. If you get an org that’s pre-populated with data, you don’t have to seed it, you don’t have to make it look fancy. It’s already done for you.
So either do a sandbox or a free trial and prototype it. And then you can put that in front of the business and get the feedback from the business. And then if it looks right and the feedback is positive, does this fall into the life cycle of where the business is at? Is this a good time to launch new functionality? And then if all of those things align, look at the technical complexity of doing it. In my case as a consultant, I’m going to be like, “Right, how much do I need to then knowledge transfer to the admin team so that they can maintain it after I’m done? If I am the admin building it, does this make sense?” And from that point you can move forward with, “Hey, yeah, let’s run with this new feature, or not.”
Mike:
I think that makes sense. Alastair, thanks for coming on the podcast and helping us walk through what can be a myriad of constant decisions in not only just the number of features that Salesforce comes out with, but the number of ways that we can build and deploy those features.
Alistair Dinning:
Mike, it’s been my pleasure.
Mike:
And I want to thank Alistair for taking time out of his day to join me on the podcast and really give me a practical way to think through what it can feel like with an endless stream of feature decisions. And here’s something you can try for the next release. I want you to take the features that catch your attention and match each one against an actual business problem or a request that you’ve heard from your users. You can prototype the strongest candidate, put it in front of a few people and pay attention to what happens. Then ask whether the timing is right and whether your team can realistically own what you’re about to introduce. A feature that earns its way into your org by solving something that matters and leaving you with a solution you can keep after you support for launch.
Well, that’s it for this week. Thanks for listening and until next time, we’ll see you in the cloud.
Today on the Salesforce Admins Podcast, we talk to Jennifer Cole, Manager of the CRM & Analytics Team at 908 Devices. Join us as we chat about business processes, Jennifer’s latest presentation at Dreamforce, and why it’s so important to understand everything about a problem process before you try to implement a solution. You should […]
In this week’s special bonus episode of the Salesforce Admins Podcast, we’re joined by Woodson Martin, EVP and GM, Salesforce AppExchange. He shares some amazing success stories of Salesforce customers that have made transformative adaptations over the past year. Join us as we talk about why a balance of speed and preparation is the key […]
Today on the Salesforce Admins Podcast, we talk to Joshua Birk, Senior Director of Admin Evangelism at Salesforce. Join us as we chat about how Agent Script helps admins build more predictable and reliable AI solutions. You should subscribe for the full episode, but here are a few takeaways from our conversation with Joshua Birk. […]
