The Inherited Org Playbook: Strategies for Salesforce Success
Episode Notes/Resources:
In this episode of Salesforce Simplified, we’re talking with Ad Victoriam Solutions Salesforce Technical Architect, Jitin Chatlani, about inheriting a Salesforce org and key considerations admins need to heed.
Chapters:
[00:00] – Salesforce Simplified podcast focuses on inheriting a Salesforce org
[01:00] – Ad Victoriam is taking over an existing Salesforce org
[03:31] – Talk about some key areas where admins should focus on documenting first
[06:46] – Let’s talk a little bit about technical debt in inherited orgs
[09:24] – Security is huge when inheriting a Salesforce org
[13:06] – Ask your client or customer how they want to segment their customers
[14:00] – Many inherited orgs run into multiple integrations that need assessment
[17:29] – Red flags include creating custom objects when you should be using standard ones
[20:23] – How do you balance necessary improvements with user adoption and satisfaction
[22:49] – Talk about your strategy for handling duplicate or abandoned automation
[25:26] – Data quality issues often come up when inheriting an org
[29:38] – Descriptions can help when you inherit an old org
Transcription
Announcer: This is Salesforce Simplified, the podcast from Add Victoriam Solutions. Here’s your host, Mike Boyle.
Mike Boyle: You know, I’ve often wondered how many folks who listen to the Salesforce Simplified podcast have inherited a Salesforce® org and just wondered what they walked into. Hi, everyone. I’m Mike Boyle from Ad Victoriam Solutions, and I thank you, as always, for stopping by the podcast. We’re going to be talking about inheriting a Salesforce org and key considerations that admins need to heed. And for that topic, I brought in a colleague here at Ad Victoriam Solutions, Jitin Chatlani. And Jitin is Ad Victoriam’s Salesforce Technical Architect. Jitin, thanks for stopping by the podcast. It’s great to have you with us.
Jitin Chatlani: Yeah, happy to be here.
Mike Boyle: So let’s just jump right into this because I know this is, you know, something that you know a whole heck of a lot about, inheriting a Salesforce org and helping people through that situation. What is your recommendation for a first-week approach when taking over an existing Salesforce org? You know, just walk us through how you assess and prioritize what needs attention.
Jitin Chatlani: Yeah, so, you know, when you approached me about talking about this topic, I really had to sit down and think about it because every use case is unique. I mean, you know, here at Ad Victoriam, we’ve worked on, you know, smaller orgs with, you know, up to maybe 50 users. And then we’ve worked on enterprise orgs that have thousands of users in that org. In each instance, I think it’s most important to understand where the pain points lie. So, that first week really is a discovery phase for me. I mean, it’s very rare where, you know, the company that’s contracted us as consultants will just say, hey, this entire org is not working for us. Can you fix it? You know, it’s usually not to that extent. Usually, when someone has approached us about doing some sort of implementation or delivery, there’s usually a specific goal that they have in mind. So that very first week, ultimately, what we’ll do is some discovery. We’ll meet with some key stakeholders and try to understand a few things. Number one is what they’re currently doing. and usually, if we’re talking to inside sales, sales reps, if they have their own in-house admin, if we talk to some folks in the C suite who are more interested in metrics and reporting, if we’re talking to sales enablement or marketing or finance, if we end up talking to those Folks we get a better understanding of, okay, what’s working and what’s not working so that, that first before we even get to org check before we even get to you know, the specifics of how many fields are being used, what the data quality is, how many automations are running, what, what is their technical debt, what apex do they have? Before we get to any of that, we identify the places that we can do the most good in the shortest amount of time.
Mike Boyle: Well, let’s talk about documentation because that’s often very incomplete and outdated in an inherited org. Talk about some key areas where admins should focus on documenting first, and maybe some tools or methods that you recommend for that particular portion of the process.
Jitin Chatlani: The thing that I would harp on the most is using Salesforce’s baked-in description field. I mean, it sounds silly, but as you’re going through the org, you know, every time you create a new field, every time you create a new automation, there is a section there to describe what’s happening in that field or what’s happening in that automation. So that’s really the first, you know, for my advice to any admin that’s getting started with an org, is that any, anytime they’re doing any sort of configuration, they should put in a description within Salesforce itself. That’s number one. That helps us immensely because you can just scroll through fields or flows or pretty much anything that’s not code, essentially, and see what it is that it’s intended to do. That’s sort of number one. The other thing is, you know, any sort of documentation, whether you stick that in a SharePoint or a Google Drive, it doesn’t matter as much to me so long as whatever document that you’re building is a live document. Meaning it can even be sort of a stream-of-consciousness thing for me. I mean, oftentimes, what we’ll do on the delivery side of things is we’ll create a deployment doc as soon as the project starts. Right? So anytime any of us on the team, whether it’s an analyst, a consultant, a tech lead, or myself architect, anytime we’ve built anything, we will put that in that document and say what it is and why we did it. And the document isn’t super well organized, but it helps us a lot because we understand again, sort of like a stream of consciousness, what exactly has been done over the course of time. So I think that would help a lot. The other thing that I think, too, is if you can document initiatives. I find that if you just have a, let’s say, you have a document where you say, okay, these are all of the flows that we have, and this is what all of the flows do. Oftentimes, you don’t really understand how those flows might be interconnected. You know, flows can be record-triggered, and so you know, if you update a field on a record, it might kick off a flow, and that flow might update another field, which kicks off another automation, and it might also shoot off an email alert at the same time. And without, if you’re just looking at a document that says, okay, flow one does this, flow two does this, without understanding how those flows are connected, it doesn’t really help that much. I mean, what I think is important is the story, right? So, in terms of documentation, I think a BRD or what you might call a business requirements document is far more valuable, right? Where you say this was the problem, this is the solution, and these are all the things connected to that solution that we built out.
Mike Boyle: Gotcha… Let’s talk a little bit about technical debt in inherited orgs. How do you evaluate which customizations or configurations should be kept updated or even removed entirely?
Jitin Chatlani: This one is tough, right, because some of the orgs that we work in are, you know, 10 years old or are older than that. And oftentimes, the reason why, you know, some code was written is because maybe 10 years ago, there wasn’t functionality that was built into Salesforce that allowed you to do that declaratively. Right, with clicks, not code. And so I think Salesforce has done a much better job, especially in recent years, of enabling admins that aren’t developers to do things within Salesforce that used to be where you could only accomplish that thing in code. I, you know, for me, my approach is one step at a time, right? And so again, it all goes back to those requirements that we deal with when we do that first discovery session, right in the first week or first two weeks. And I think what I like to do is identify an object or a process that needs remediation, right? So let’s say it’s their sales process or, or something to that effect, where you’re dealing with, you know, the objects, lead, account, contact, opportunity, asset, maybe contract, order. These are sort of the standard sales objects. And then you sort of go one by one and identify, you know, hey, let’s look at what automations are tied to the account object. Let’s look at what workflows may still exist or what Apex triggers still exist that are tied to the opportunity object. And then you sort of slowly work your way through. Never really helps an orb to go through it. To me, it almost feels like a waste of time to say, okay, let me look at all of the Apex triggers in this org and then determine what’s still viable and what’s not, what we need to get rid of. It makes way more sense from the perspective of wanting to make the org more usable for the end users by approaching it at a you might call it a sub-project level. Right. So you know, let’s, let’s get the sales process in order that we can move on to the lead process, then we can move on to customer service or whatever it is, and you go object by object and try to identify that technical debt that way.
Mike Boyle: Well, we certainly can’t have this discussion, Jitin, without talking about security, that’s huge, and sharing settings. Those things can be complex to untangle, as you’re very well aware. So, what’s your systematic approach to auditing and validating existing security configurations when inheriting a Salesforce org?
Jitin Chatlani: Well, in Salesforce, I like to think of sharing invisibility and permissioning as a kind of Etch-a-Sketch. Right. You’ve got two, you know, two dials. Maybe it’s a complex Etch A Sketch where you have a couple more dials in there until you get the full picture. But I like to break it down into what you can do and what you can see. Those are my two main categories. Right. So, my first approach is to understand what you can do. Again, you know, I don’t want to harp on it too much, but you do have to talk in-depth with the client or customer or whoever it may be to understand exactly how they’re attempting to use Salesforce. If they’re hiring us, Salesforce probably isn’t working for them, or they’re wanting to add some functionality that they didn’t have before. So that first question is, what can you do? Is it important now? The challenge with older orgs, ones that you inherit, is that you know, permissions at the profile level dictate what you can do. Right. So roles and sharing settings and those things – org-wide defaults – those determine what you can see. For the most part, what you can do is, tends to be at the profile and permission set level. And the challenge with a lot of those older orgs is, man, they’ve got a lot of profiles sitting around. So, the first thing, usually, and this is more from a broader perspective, is you look at the users. And you look at what profiles are associated with those users. Now, I won’t say that I do this, you know, by hand. There’s a lot of tools out there that can help you with that. Salesforce Labs has one that you can download on the App Exchange called Org Chat. It’s a fantastic tool. It’s free to use, and it does a lot of things for you. It tells you how many users are associated to what profiles and how many permission sets there are, if they’re even being used. You can see how many fields are being used, what you know, how many fields have what data populated in them. It can do a lot of things. It can even give you a visualization of all of the roles that are in that org. And then, you know, you systematically look at what profiles are actually being used. You identify what needs to be done right from again, answering that question: what can I do in Salesforce? And you apply that to some general business roles. And sometimes, it’s one of those things where you cut your losses, and maybe you create a new profile. That’s sort of the new best practice around what that question of what you can do the profile level. It. There’s some new best practices that Salesforce is asking us to consider, which is to use permission sets for that. You know, you might have a baseline profile that you build, and then you extend permissions using permission set. And I think that’s kind of the way of the future for Salesforce. Profiles are getting really robust now. They’re getting too complicated to manage because there’s just so much going on in Salesforce that I think permission sets really are kind of the new way to handle the permission set groups.
And then the second question of what can I see? I think that, too, you may need to ask your client or customer. Okay, let’s think about simplifying this. Then, you ask them, maybe, how do you segment your customer base? Is it territory-based? Do you do it based on some other aspect, like industry type? And then once you kind of understand how they want to segment their customers, you can make some considerations, and you can advise on. Okay, we need to set up the role hierarchy this way. All that being said, the approach that you should take as an admin should go from private and expand from a sharing visibility standpoint. You start with the least amount of visibility and work your way up. And I find that to be an easier method to control things.
Mike Boyle: Another thing many inherited orgs run into… multiple integrations in place. And just curious how you recommend mapping and assessing these integrations to ensure that they’re still necessary and that they’re also functioning properly.
Jitin Chatlani: This one is probably the toughest aspect of inheriting an org because there’s not really an easy way to understand what is going on in that work from an integration perspective. It’s not as if there’s a place that will tell you, especially if you’re doing callouts via Apex or something to that effect. Salesforce does have within setup that there is an event monitoring tab, and it’s not the. I wouldn’t say that this will solve all your problems, but at the very least, it gives you some insight into how many API calls are happening and then potentially what objects are affected with those API calls. Now again, you’re limited, right? I think you can only really see what’s happening with the Salesforce Rest API. So there might be other things going on, you know, utilizing MuleSoft® or Dell Boomi or some other middleware that is harder to identify in this. In that aspect, you are somewhat at the mercy of whatever documentation existed before. You can always improve on that, obviously, if it’s done poorly, and make sure it’s easier for people to understand. Okay, what exactly is happening, you know, in this org, whether there’s some nightly batches that are making calls and moving data from one place to the other or whether you’re doing live call-outs or asynchronous call-outs to another service to pull back data into your Salesforce org. I do think that there are tools that Salesforce, I shouldn’t say tools. There are products that Salesforce has introduced in recent years, like Data Cloud™, for example. That, I think, is a good landing zone for all of those integrations to pull in data into Salesforce. That makes it easier to kind of understand, okay, where is all of this coming from? But yeah, I mean, I think you’re a little bit at the mercy of what documentation is out there already. And hopefully, you know, your client that you’re working with has some sort of documentation, other than that, you know, you’re, you’re going to have to kind of look and see, look at what scheduled jobs there are for Apex. You can look at if there’s any web components that have call-outs in them. That one is more of the investigative part of our job when we’re trying to understand, okay, what is what systems are integrated. Another tool, I guess, another good way to look at it, or another place that you can look. Oftentimes, when you’re setting up integrations, you do have to set up a connected app in Salesforce. And so sometimes just by perusing like, let’s say connected apps or named credentials, some of these custom metadata settings or custom settings that are in that org, you can piece it together and understand, okay, there’s probably some integrations running and especially if those integrations are using OAuth to connect to Salesforce. S,o you do have some tools at your disposal if you know where to look.
Mike Boyle: Justin, are there any red flags, you know, maybe one or two that you could give as an example for an inherited org that would make you immediately concerned, and maybe talk about how you might address them?
Jitin Chatlani: The biggest thing I mentioned before was when there’s just no description information within the org anywhere, right? So if you’re looking at even basic, you know, standard objects like the account or the opportunity, and you’re looking at the custom fields, and there’s just no description of what those custom fields do, then, you know that you’re in trouble a little bit, right? Because you have no clue, a lot of the red flags have to do with creating. Net new things when you should be using existing things. And what I mean by that is sometimes you you’ll inherit an org where you can tell, you know, perhaps the admin that had worked on it previously was maybe kind of new to Salesforce. I’ll tell you, I mean, what happens a lot are things called accidental admins. And I’m sure you’ve talked about it on the podcast before, perhaps where, you know, someone gets to be the Salesforce admin because they just showed interest in it, but they had a job previously that had nothing to do with Salesforce. And oftentimes, what happens is there is a process or a workflow or something that they need to achieve that you could very well achieve using standard functionality. But instead, the, you know, whoever had worked on the. org before choosing to use a custom solution, right? Whether that’s an app exchange package, or whether they created a custom object for something that really should have been done or using a standard object. And, and, and so when we see things like that, when we see, you know, an abundance of page layout all assigned to, you know, different users for the same object, we see a lot of profiles. Those are red flags. And, we know we’re going to be in some trouble or not. Maybe not trouble, but a little bit of hot water just from the level of effort that it’s going to be to untangle some of that. But that’s the major red flag for me is when there’s just no descriptions on anything that says, okay, what is this intended to do? Yeah, that’s a tough one.
Resources:
How to Keep Your Salesforce Org Secure and Up-To-Date
Set Up Your Salesforce Org for Integration with MuleSoft
