Description
Technical debt can slow down and limit the growth of your Salesforce organization, but with the right strategy, it can be turned into a valuable asset. This presentation highlights how identifying knowledge gaps while examining technical debt can lead to better training for admins and developers. It stresses the importance of thorough documentation, following best practices, and regularly evaluating the system. These actions not only reduce technical debt but also help teams create and sustain an efficient and strong Salesforce environment.
Lynda Kane – Senior Salesforce Developer, Cerity Partners. A 16-year Administrator/Developer, Lynda is very active in the Salesforce community leading the Cleveland, OH Developers Group and hosting #SalesforceSaturday meet-ups.She is also a facilitator for GirlsWhoCode and a seasoned crafter/artist.
Joy Shutters-Helbing – Sr Manager, Salesforce Practice, CapTech Consulting. Joy is a Salesforce Champion turned Admin then Consultant, with a few stops to Dreamin events and detours along the way. 20 years in the SF ecosystem, Golden Hoodie recipient, Co-Leader of Chicago Admin Community Group, SF MVP, Co-Host of MVP Office Hours.
Transcript
It's bound to happen. There's no railing. There is no railing. No guardrails. It's like building a production.
So, all right. Are we, I think You keep pushing buttons.
I didn't push that button. Now we're ready. The man behind the curtain is pushing buttons.
All right. We are good to go. We're good to go. Hey.
Can we, take the little box off of the big box?
Got like a double display going on.
So we had some technical difficulties and, we're gonna work through this real quick. Before we get started, if you're here for this is ridiculous.
What? This the what? Yeah.
I did I did pack a hat, you guys. But I do have these fancy sunglasses that Bryce gave me, which means I can see less of you even though no. No? Okay.
Do it. Do it? I can't I can't no. I will fall.
I want it back.
Thank you.
I got sunglasses from Bryce and I got a hat from Alex.
You'll get it back Alex. You'll get it back. I'm not supposed to take swag home.
We need to go back at Costco.
At least this time or two or yeah.
Okay. So if you're here for transforming technical debt to technical wealth in your Salesforce org and to meet us, Linda and I, you're in the right place. If you're not, then, you know, just chill because it can get really weird really fast.
Do you wanna, let's see. Oh, next slide. All right. This is Joy.
Hi. I'm Joy Shutters Helding. I'm a Senior Manager at, we're at CapTech Consulting in the Salesforce practice. And this is my friend and former colleague, Linda Kane.
Hi. I'm Linda Kane. I'm the Senior Salesforce Developer at Serity Partners.
I've been in the ecosystem almost as long as Joy.
Combined, we have almost forty years of Salesforce experience. So, I know, take a deep breath.
We are also both user group leaders.
We are and, I'm in Chicago. So if you're local, the Chicago admin community group is is a hopping place to be. Denise, my co leader is right here. Also, everyone say hi, Denise. And Cassie is here, for our nonprofit Chicago and Andrea is here for our suburban admin group leader. Is there anyone else in the room?
And gosh, Chicago leadership showed up today. I like it. Linda, where are you?
I'm in Cleveland, Ohio and I run our local developer group.
And Salesforce Saturday. And Salesforce Saturday. And she crafts the heck out of all Salesforce things. So I don't know if you noticed her awesome little vest here, but it's got, are those all the badges or super badges? Like what?
So I have all the super badges.
All these pins are super badges that she's completed.
And then I have my certs.
And her certifications that she's gonna- There are no super badges I haven't completed. There are no badges that Linda hasn't completed So, this is the background on Linda.
All right. So, let's get into our presentation so you got to know us and all that good stuff.
I'm going to talk about definitions.
We're going to start with definitions because, you know, we think we all know the world what technical debt means. But technical wealth, that's kind of a new word.
Technical debt, got that. Technical wealth, what do you think you're talking about Joy?
Well, let's start with technical debt.
All right. Technical debt. So, this is a great quote.
It is.
I'll read it for you. Okay. It is. Technical Debt is a measure of the amount of duct tape holding your system together plus the amount of rust that has accumulated.
I don't know what you all drove when you were in high school, but what I drove needed duct tape because it was rusted out. I actually I did this. I did this. I actually just talked about this the other day. But what else do we wanna say about this?
So, it's really that culmination of everything that's happened in your org. All those customizations you've created, all the things that Salesforce has told you they're retiring and maybe you were using and didn't get rid of, but it's those performance issues that are happening are are part of it. The the gaps in knowledge in your team and what what was developed five years ago that nobody remembers and configs that are just out of date, you know. Maybe you're still using an outbound message somewhere but it's not really reaching.
Or maybe you're using the old approval process when you got approval flow orchestration ready now.
That's what I'm learning right now.
So are you ready? You want to record? Yeah. So, technical wealth and you're like, okay, just get me some of this.
I know you wanna take photos, I know you do. We can give you all the slides. And they're gonna be provided by DevOps stream, but you can take photos.
I don't wanna stop you, but you will get the whole deck in a little bit.
Knowledge is a source of wealth.
Applied to tasks, we already know. It becomes productivity.
Applied to tasks that are new, it becomes innovation.
All right? So that was Drucker.
And having a system like this.
So, I I know you guys all heard well architected but when we have technical wealth, we have well documented, well maintained and well understood. So, now we're just expanding all the wells.
Well architected to wealth. It's fantastic. All right.
So digging in a little bit. Identifying tech debt. This is, I know you are ready. You all have your checklist in front of you and you think that we are gonna show you some amazing stuff and you're right.
But there's more to it, right? Yeah. Okay.
Identifying tech debt is knowing is half the battle. Understanding you have tech debt and where you can find that tech debt is half of the issue.
So, what are the knowledge gaps? You know, talk to your admins, your developers. What don't they know about what's in the system?
Because we need more training, we need more documentation as admins and developers. And then what do your users know and don't know because that's also TechNet.
Now. They don't know how to use the system properly.
Do you know?
I actually had this happen. We just talked about that. Who did I talk to about this yesterday? EJ? Steve?
I don't know.
Someone had talked about how a user didn't know how to deep dive into figuring out what happened but that was the deep dive into figuring out what happened, but that was the situation.
But, like, training your users is as important as training your Salesforce staff. Right? Yep.
And what about inconsistencies?
You know?
What about what? Inconsistencies.
Like, so I develop a flow today and I put all these things in it and I do all the good things like, yeah, descriptions.
And then my teammate makes this other flow and puts none of that in.
You mean the formulaic best practices that you've established over the years of working in the system that you tried to teach me when I was doing git? Yeah. Like, okay. Yeah.
Those naming conventions, those special links, all those things that make the experience consistent from one employee to the next within your team. So that like Linda's documentation is always amazing, but my documentation lives up to her standards. Like just making sure everyone has their formats and good stuff.
And performance issues, you know, where is stuff running well? Where is it not running well? Where are you getting tickets because the user said, hey, this is taking too long and can I get to the point where I know it before the user tells me because that is the ultimate goal? Can I tell before the user knows the system is actually slow?
Linda, I love that you like to just like beat the user to the complaint. Yeah. Beat them to it. Don't let the user figure out that they have a problem. Find it for them.
And then just as you assess the technical debt, develop a cadence of it. Do it regularly Mhmm. And communicate it. Because if nobody knows where that is, there you're gonna end up in that conversation down the road about, oh, we should move to HubSpot or to Dynamics or and you're gonna spend a lot of time defending your product.
This is this is this is a thing.
Like, if, if the maintenance isn't handled on a regular basis, right? I mean, you all cleaned your rooms this week, I know. Maybe you made your bed. It's the same thing.
It's like technical wealth, technical debt. Like if you make your bed every day, it's not a mess. If you clean your house every week or if you put air in your tires and you get your oil change in your car, all those things are maintenance that you do on the other parts of your life. Apply that sort of maintenance to your Salesforce work.
Well, and whatever other technical things you work on.
So, top of mind things, Kind of things that we have to keep in mind when we're dealing with technical debt and identifying.
Obviously, the more we've customized, there's more potential for that. That doesn't mean it all is debt yet, but it could be.
And not all technical debt was self created by us. You know, how often do you get those messages from Salesforce saying they're gonna retire this feature?
You know, we thought that we were gonna use it forever.
I mean, yeah. So, like, for instance, like, if you have Classic running in your org, it's okay, Andrea.
I've seen it recently, it's wild.
If you have Classic running in your org, that's tech debt, right? Like Salesforce has moved on.
That's something that you're gonna need to address.
And that is an extreme- Or do you have workflows or process builders?
Do you have workflows?
I actually just had a process builder conversation this morning. This is wild, we're touching all of this. Process Builder that's been in place since twenty nineteen, the person who put it in there is no longer associated with the company. There's no documentation, no one knows why it's there, but it's active and wrecking havoc on all sorts of things. So the request was, can we deactivate this across the board? That happened today. I mean, you could try.
I'm not touching that one with ten foot pull. Someone else has got that one.
The other thing is Salesforce, especially on Salesforce, is a moving target. Three releases a year, API number changes every time, your stuff is versioned whether you versioned it or not yourself. It's versioned.
Especially flows now.
And things start breaking when it's the wrong API version.
Or when you try to deploy a fix to it and it's an older version and suddenly the feature you thought you built isn't there when you deploy it.
And really all this is about really wanting to know before. We wanna know before the issues and failures happen. We wanna know before someone asks us to create that shiny new thing, what's going to prevent us from creating that shiny new thing so that we're not going back to them and saying, well, your shiny new thing is going to have to wait another three weeks while we fix these fifty other things.
Linda, are you talking about this shiny new thing called Agent Force?
Not only. I mean, that's a shiny new thing.
Well, that is a shiny new thing that we've all heard about ad nauseam with Salesforce.
But I've been not trying to say that word. That's right.
I'll say it.
But if your descriptions are garbage or don't exist, Agent Force doesn't like it, it's tech debt, fix it. If all of your field names don't match, like field labels and API names don't match up the way they should because you didn't clean up properly when someone's like oh, we want to rename it this but we don't want to do the work to go back through the thing.
It's a game. It's a game. It's a game.
It's a game. It's a game. But it's really hard for people to work with.
When they're likely you're gonna choose the wrong thing when you're developing.
But these are the sorts of things that like if you fix them as you go or if you fix them as you understand they're a problem or document them, then when it's time to have the shiny new things, you can prioritize the things that need to be fixed also.
And then, difficult conversations.
They're going to happen.
We can't avoid them entirely. What kind of difficult conversations, Linda?
Which one do you want to start with? I built it wrong. We have to take more time to do something. We you don't this is something that's not even visible to you but we have to work on it. Yeah. How do I explain that to a stakeholder that I have to work on this thing and no one's gonna see it?
So I'm just wasting, you know, your three sprints. You're not wasting. Yeah. I'm not wasting. But to them and to the end users, I am.
Because it's nothing's visible to them.
Yeah. Okay. That is a difficult conversation.
I'm telling stakeholders they have to wait.
Or telling another developer that they didn't document.
Or asking another developer to learn your strategic system of documentation?
Yeah. Come on, Linda. It is. It's confusing. Here's that list. Go ahead and take that photo if you want. It's not extensive.
It will and it's not because I couldn't think of everything. But just all the different things you might want to look at for technical debt and just know that you don't have to look at all of them at once.
You can chunk out the things that are low hanging fruit. You know, maybe you've got some inactive users even. That's a really good one.
But- Inactive users isn't on there, but inactive users that still own stuff.
Yeah. That's true. You know? How often does your sales team call you because so and so owns an opportunity they're working on and that person's not even here?
Oops. Jimmy Bob is no longer working here. We gotta get him off those. But reports and dashboards, that's an easy low hanging fruit item that you can work on very easily tomorrow.
But there's a lot of these things that, you know, maybe you haven't discussed. So, this is a starting point. I think that all of you would like to look at this and we'd play like a little game of like, you know, what is the game called? Where you like name the things and you cross out who has the same things, anyway.
I just feel like we could play bingo.
Oh, we could play bingo. But, you know, rip off this, identify and brainstorm the rest of your things and you're gonna start seeing the technical debt like in a different light, I think.
So. Okay. Ready? Yeah. I'm ready. Okay.
So, there's tools out there to help you. You don't have to do this alone.
Queries and reports number one.
Write a query.
Write a report.
This field is not filled in on any record. That's easy.
Last modified I'm gonna follow your course.
As we get to the next slide, I have a bunch of what are the tooling API queries that I use for kind of the more programmatic technical that Yeah. They're super useful and easy.
Now that there are easier ways to run it.
Well, especially when I'm giving you the whole query. Well, yeah. And then observation and knowledge. Just ask.
Ask your users, ask your admins, ask your devs, what are the things that are going wrong? You know? Make that part of your retro. What are the things we saw that we didn't fix while we were doing this building the shiny new thing?
When was the last time you sat next to like one of your super users, your Salesforce champions and you're like, so tell me what you hate.
And you're gonna find technical debt because they're like, well, every time I log in I trip over this thing or I've gotta close this screen that always pops up that is from twenty twenty. What the heck, Linda? No, I'm kidding.
Linda, when did you try some stuff yourself and see how slow it goes? Right, see how slow it is.
And then tools.
Oh, all the tools. All the tools.
Which is your favorite?
All of them?
I mean, for a while I really liked Optimizer but then they kind of took it away partially and it sounds like they're taking it away again. They put it back partially but I don't know what it is.
I don't know what it is. We don't have the answers on that. Safe harbor, I guess. But, Yeah.
There was an announcement that's going away, then there was a retraction and then it was announced again.
So I don't Uncertain at this point in time where it stands.
So, so So so one of my goals is to try to rewrite all those queries.
So lately, I've really been using PMD a lot. But as a developer, trying to figure out whether my code meets best practices and whether I'm gonna get security issues down the road is kind of important, especially in a new org.
But there are third party tools out there. I know Ian's here. He'll tell you all about elements.
Actually, Ian's somewhere because his badge is here.
So, Ian, if you're around, we have your badge at the front of the room.
And someone was trying to convince me to try Sonar and I hear there's a free version now. So, I need to check that out. Interesting. Interesting stuff. And there's other tools too. I just couldn't remember them off the top of my head.
There's so many tools out there and every tool is right for someone. You just have to figure out which tool is right for you and your org.
There's a good reason for all of them but.
So I did promise some queries.
So the first one on here is code coverage.
Again, we'll share the deck. Like when you mention tech debt to a company, this is like the first thing they say, oh, but my code coverage is great.
Maybe overall, but you've got to have an if your code coverage is not one hundred percent in your org somewhere, there is a class that is not good somewhere. We have seen something. So, this is the query really behind that calculation.
But this gives it at the class level. So, I have individual classes tests recently in your org. If you have not run tests recently in your org, you're gonna get a lot of zeros when you really have tests.
So one of the things I'll point out is of the things I'll point out is Gear Set allows you to schedule Hi, Gear Set.
Test runs.
And I literally have that going in my developer sandbox and our production and our staging because I'm watching.
Linda, you're always keeping an eye out for our users.
And then the second thing I'm gonna put on here is the part one of getting into API versioning.
So, what things at my org have an API version that is not the current version? You know, we're on sixty three today.
Sixty three. That's a really big number.
What's the oldest, what's the oldest that you have in your org right now?
That I have in my org right now? Thirty five. Oh.
My my Has that been identified as an item to address Linda?
So it's from a managed package. So it's not my fault.
Hey. So it's been addressed. It's been blocked by the vendor.
It's not been it's not been addressed, but it needs to be addressed because maybe I need to upgrade that package. So what's the name of the Nasdaq? But it's it's it's an indicator that I need to do something. Mhmm.
So, this first query is a really simple, you know, I'm selecting the name and the API version from the various pieces of metadata. And I can do this from Apex class trigger, Apex page, which is a Visualforce page. Mhmm. And Apex component which if you have any in your org, they're like snippets of the Visualforce page but not the whole page.
The cool thing about this particular query is I don't have to be in the tooling API.
This is the only one of these that I don't need the tooling API for. I can run this just, you know, whatever thing I want to run it in. It's really annoying. So when I run a lot of these queries, the first times I do it, I do it in, like, dev counsel because, you know, fast and cheap. And the only sucky part is it's hard to get stuff out of dev counsel easily.
Like, it doesn't down the results don't download easily. Alright.
And so sometimes maybe you gotta do it the right way.
So then my, if you haven't tried Salesforce Inspector Reloaded, totally recommend it. Very cool tool. It will run both regular and tooling queries and but you pull them out to Excel, CSV.
If you really want it in JSON, you can get it in JSON.
I gave a presentation last year with all these queries and I just discovered the Postman API. It's fantastic. Which is really cool because there's a tooling API in it. But that gets into JSON again and then figuring out how you get JSON formatted so you can use it is lots of fun.
But, you know, there's options. And the nice thing about using it through the API is then I could schedule that from another system and get it in my warehouse and see see stuff over time. Alright. So go to the next one. Gotta keep moving. So the next one, on the left is the one I the version I'd use for my lightning components, both the aura and the LWC, just slight difference in the object name. And the last one is flow.
Flow is huge. But, the only problem with this query is it gives me every version of the flow in my org. You know, when you develop a new flow and you replace it, you have that old version still there unless you've managed to physically delete it.
Storing that old version is tech debt because that old version might keep you from getting rid of something else that you wanna get rid of.
And it's all tied up.
So you so you so you made a new you have a new field in your flow, and you're trying to get rid of it from your org because you don't use it anymore. As long as that old version of the flow is there, you can't delete it. It's gonna stop you. Okay. Just keep that in mind. Another level of tech tech.
So after I do all this and I put all this together, I should be reporting something.
I should, which of those measures that I collected do I really want to report on? You know, I don't have to share everything all the time. I mean, maybe to my boss I do but I'm not sure I wanna tell the CEO all of the things that are wrong in the org yet.
Yes, you should share this to your supervisors. Yes. Yes. Yes. Yes.
Come up with a rating system. You know, one of the things that those stakeholders are gonna ask you is, so get what's the overall picture? Well, is the overall picture an a, a b, a c? Is it a hundred we're a hundred percent great? Is it we're a red light or a green light or a yellow light? Like, come up with some kind of rating that makes sense that you can explain and that I mean, I report on like five different measures and I have five traffic lights in my report right now.
Lights are fun. We like it.
We like it. And just standardize on the format used for the reporting. You know, make sure you so you can do it quickly, easily, repeatably.
Yes. Yes.
And you can That sounds like well architected. It is a little bit. Alright. Yeah.
Sharing it widely, like, the stakeholders.
My Salesforce team should all know where we're at so that we're all telling the same story.
Yeah. Yeah.
I mean, my user prioritization is is impacted by this too.
And I want my users to have awareness. You know? If you're seeing something, please tell us. Mhmm. Because if I can tie it to one of these things now, I'm gonna fix this thing sooner. And then some extras. So one of the things I did in my most recent job was I looked at all the tech dot things and I said, what can I accomplish in a year realistically given that I'm I know I'm gonna be expected to build some new shiny things?
Yes. And I'm gonna have to fix some things that maybe aren't mine and help my other developers and admins and all the other things that I do.
But establish a few goals and not a lot. You know? Three three is usually plenty.
And then just track those. Where am I out then?
In my document also that I'm sharing, have an appendix with how you got there. You know, what did I actually have to do to calculate this number so that I remember the next time I have to refer?
Let me tell you, Linda has got a document of links that would make your head spin of how she has like done all the things.
She's like oh, hold on. I have that link. I'm like what? She like sends me this link. I'm like that is so obscure and helpful. Thank you.
So obscure and helpful.
And then a task list. What did you just complete that's relative to TechEd? What do you have on your plate that you're going to look at soon?
Just keeping people informed where we at in this journey of resolving and keeping our org running and smooth and up to date.
So, resolving.
We're going to have to pick up the pace I think. Okay.
Pick up the pace.
What's our timing? What's the next session start, anyone? There's a break next? Okay. We're keeping you from snacks.
Here we go. So, it's not about perfect. We are not gonna get to perfect.
Salesforce keeps changing stuff on us. We can't get to perfect. But we can be organized. We can improve our development process. We can institute best practices and standards.
We can train and mentor ourselves and our coworkers and our users. And of course, we can track the metrics we just talked about. Fly. Quick wins.
This was Joyce. Oh, yeah. Quick wins. These are great. So, we already, I already shamed all of you about your description fields because, you know, I know you didn't fill them out because it wasn't required.
Yes. You have blank description fields. I know it. Fill those in.
Establish and follow some naming conventions. Create the documentation that Linda's talked about in a way that is understandable to all your users and your staff.
Codify the error messages and validation rules. This is actually like one of, this is brilliant, right? So your validation rule has a code A1, B2, whatever it is, so does your error message. So when you get the screenshot from your user with the error message, you can match it up very easily.
It's one of the most brilliant things that someone ever presented to me and- Or if you're a developer and you get that error message from the Apex, you know it now.
It's validation rule. That's the problem right away. Use comments in the formulas.
This is also one of those things that if you don't know how to do it, figure it out.
Because it was a star slash and slash star to write slash forward slash back.
Or double slash if it's along the same line.
There you go.
Making it part of your build process. Yes. So I'm working on this flow. I'm gonna bring it up to the most recent API as part of what I'm doing so that that becomes a habit and now it's not typed out on my list.
Establishing practice. That's what this is all about. Defining those best practices. What are the best practices for our team? Not just what Salesforce recommends, documenting those standards, having checklists.
You know? We're gonna get into code config reviews. A checklist for what you're looking for is you need it. Like, I can't tell you how many times I looked at something and missed it because I did have a checklist.
Ongoing training, retrospectives, not just for Agile. Get your team together once a quarter and talk about what's working well, what's not working well, what issues might be presenting themselves soon that nobody thought about.
And then have that process in place for reporting potential tech debt. So as a developer is doing something and they say, hey, I'm gonna run fast because my sprint's done in three days, but there's this thing that if I wasn't running fast, I would probably I should fix. Let me have a way to get that added for a future sprint.
And then code config reviews, I'm a big proponent of this. I don't care if you're developing code or if you're just adding a pick list value. Someone else needs to look at it, not just you.
So having that checklist to make sure the things that we're trying to establish in our company are followed and that being a revolving list so that as the team has embedded doing those things, they don't have to take as high priority in that checklist. But as new practices get defined, they're in it. And as I see issues happening over and over again, I can add those to the checklist so that they get taken care of and it becomes less of an issue.
I mean, we were at a company for a while and let me tell you, Linda added stuff to that checklist a lot.
It was great. And I took stuff away too because it was not a problem anymore. It was great.
Having it part of the release cycle. Gate your releases.
And then your reviews could be synchronous or asynchronous. You know, I can have a meeting with another fellow developer or I could have a meeting with my development team so that they're learning from this code review.
Or I can just you know, it's part of my pull request. I have that, and they can just look at it and do it. But some mix is often the best way to go.
And remember, code reviews focus on your building, your ability, and your knowledge. It's not about assigning blame or saying you don't know what you're doing.
Even though that's what the button says. Right? Get blame.
That's Get get blame.
That's different. That's after there's a problem. But, you know, really focus on that code reviews being a way to build up not to tear down.
And then, obviously, building a library knowledge is the documentation piece. Figure out where you want to store it, what do you want to store.
How are you going to make sure it's recent and maintained? You know, you don't want to create a document and then you've changed that flow thirty times and it's no longer any good for anybody.
And then communicate that where it is often. Like, you need to be able to find it. Your developers need to know where that documentation is. You're, you know, if it's a knowledge base of articles that you're sharing with users, they should know where to go first so they don't call you.
Hot spot of activity.
Make it a place that everyone can access when they're supposed to access it.
And are we done with this one? Yeah. Go on. Text, oh, we gotta go fast. Linda.
This is short. Okay.
An investment of knowledge pays the best interest.
I love it when someone who likes to tie kites to strings gives them a good cross.
And we all know who Ben Franklin is. You want to, you know, foster the environment to encourage growth and learning, just to make sure that your whole team can build up the things and move forward. I feel like we really have to fast forward through this.
Okay. So formal and formal methods of sharing we talked about and just make it part of your daily practice.
You know, identifying the type that as you're moving along, fixing it as you're moving along as well along with designating part of your sprint for doing tech tunnel or- I mean, this is what your autumn sprint is for and you'll hear more about this from Steve Moe.
Steve is not here. He talked about this autumn sprint and I'm just dying about it.
That's when you do all the things and you're like, yep, that was Salesforce's autumn sprint, all that tech debt taken care of.
It's not real. It's not real. It's not real. But the idea of making it part of it, you know, you're never gonna get that. Yeah. Go work on tech debt all the time.
Not realistic.
But make it part of it so you reduce and don't have as much. Ready? Yeah. So, yeah. I always have links and this will get shared.
So some articles about tech wealth, a really cool podcast about inheriting code. Yep. Not just Salesforce. In fact, barely ever Salesforce, but totally every issue we have.
The last one is your The last one is is the document I have of all the queries I like to run.
So the ones I presented along with some extras Mhmm.
Along with the tools that go with it. And then the other the one right above it is a checklist from Salesforce, actually, about developer best practices. They have within the last year updated that article, which is cool, the fact that they're maintaining it and making it available.
All right. So, I think we're past time. I know you all want snacks. I don't know what the snacks are.
So don't ask me that one.
Are there any other questions?
In the back.
The best way of educating your a bad way? Just giving them a document and not telling them a thing or showing.
Actually, the worst way you can educate your Salesforce users would be to give them their login and no direction. That would be the worst thing you can do and I see it happen all the time. Was there another question?
I will say a good way for educating users is to make them drive.
Literally, make them drive. But that's great.
Have them show you the screen and make them drive and then walk them through.
The one on one trainings, I mean.
Yeah. So, I think, is there anyone here from- Is Claire still here? Is Claire here?
I believe all the slides are gonna be shared through DevOps streaming but we will actually- If not, it'll be on my website.
We'll find out. Put it on LinkedIn.
Yeah. Yeah.
You can go to the next slide. The next slide has our contact stuff. Oh, yeah. Here's it. So you can find our LinkedIns if you want to.
Yeah, you can follow us on LinkedIn. You can, well, I'm all over LinkedIn so you guys will find us and and I can always find Linda because she hides out from y'all.
But thanks so much for sticking around with us through the like start of snack time. Thank you.
Thanks, Linda. That was great. That was great. Thanks, AB team. You guys were great.
I owe Alex a hat. Bryce said I could keep my sunglasses.
I'm not supposed
