Description
In this fireside chat, Tom Leddy and Claudia McPhail discuss the challenges of managing multi-org Salesforce environments, including deployment complexity, customization drift, silos, and increased costs. They will discuss real-world examples to illustrate the struggles organizations face with multi-org setups and their experiences working with and researching complex multi-org implementations, and the key problems faced by teams who attempt this key stage in their DevOps journeys.
Tom Leddy – Technical Architect Director, Salesforce. Tom Leddy is a Technical Architect Director at Salesforce. Tom is a published author, public speaker and marathon runner based in the Chicago area.
Claudia McPhail – Associate Product Manager, Gearset. Claudia is an Associate Product Manager working for Gearset, a leading Salesforce DevOps platform. She works closely with users to uncover their goals and understand them deeply, making evidence-based product decisions and translating user needs into product strategy.
Transcript
Awesome. Hello, everybody.
Hi, everyone. All right. So, we're gonna talk about multi org complexity and we're gonna be up here doing kind of a fireside chat and just making this kind of an informal and fun discussion. So, it is great to see everybody.
Nice.
Let's start with introductions then. So, I'll go first. My name is Claudia McPhail. I'm an associate product manager at GearSet. I went to GearSet around five ish years.
I don't know if we're doing fun facts, but if you want a fun fact, I actually grew up in Chicago. Not Chicago. So Detroit, which is just over the way from Chicago. Oh.
Which, obviously, I don't live in anymore. I live in the UK, but that's kind of always interesting when I come back to this part of the world.
And over the last couple of years, I've been focusing on researching how we can help people through the use of multiple DevOps and what that looks like in a in a Salesforce world.
Awesome, and I am Tom Leddy. I'm a Technical Architect Director at Salesforce.
Been at Salesforce for about eight years or so. I was part of the well architected team and I work with a variety of different organizations now to help them with their overall architecture strategy. And been working in the Salesforce ecosystem more than, since about twenty ten or so. So it's been quite a while, so. Nice. Awesome.
All right. So let's talk about, first of all, why is an org strategy important? And I know it's something that you've been working quite extensively with a lot of customers as well, right?
Yeah, absolutely. It's very much one of those fail to prepare to fail kind of things.
And it's something that we found is increasingly important for businesses as they scale as well. As businesses, begin to get more complex, as they expand, as they grow, org strategy becomes increasingly critical to their ability to do that with resilience and with visibility and reportability for the kind of business as a whole as well.
Yeah, and I can tell you from with all the different customers I've worked with, unless it's a very, very small business or like a small nonprofit or or something. You get to a certain point where, you're not gonna be able to scale your operations if you don't have a good org strategy in place. And that might mean that your org strategy is we're gonna stay in one single org and that's great but if you're gonna expand out to multiple orgs, just thinking about how you wanna strategically approach that is essential to keeping your implementation healthy.
And there's actually sides. So there's from the business perspective, you need to be concerned about customer visibility. If you have multiple orgs, are you gonna be able to see all of the information about your customers in one place still or how are you gonna be able to get access to that information?
Being able to report across orgs, cross department collaborations. So a lot of times what we'll see is organizations that have multiple departments, each one has its own org. Well, if you need to hand off processes across those departments, from a business perspective, you're gonna need to care about that. Like where is the data that those processes need stored?
Like what org is it in? And then how do those handoffs occur? But even IT, you need to be thinking about licensing, right? Like if you've got multiple orgs, what that might also end up meaning is that you've got the same users logging into more than one org.
You've gotta purchase licenses. So you need to really be thinking about some of these things as you put your org strategy together. So those are a few examples.
Nice. Nice. And this is a question that we find is increasingly being presented to businesses whether they like it or not. Whether they want to or not, they need to start thinking about having an org strategy organ that being a decision that they have to make. Because as we increasingly, kind of build in a world that is regulated by data compliance regulations, we need to think about how we are dealing with those concerns, as Tom says, about are people logging into multiple orgs? Are we getting mixed sets of data where there shouldn't be? And how we can support the requirements of IT, of the business, but through the lens of Salesforce.
Yeah. And there's a couple of different reasons. So, from a business and IT perspective, you might wanna, if you're thinking about why you would choose a single org versus multiple orgs, you've got that three sixty degree view of the customer, you know, handoffs, trade, you know, support. There's a lot of reasons why having everything consolidated into one org might make sense.
And, you know, there's a couple, tradeoffs that we'll look when we get to the next slide about why you might wanna choose multiple orgs. So, if we start to think about, there's a couple of reasons. So, one is legacy, you've got legality issues, so you've got compliance issues. So, one of the things that we're finding more and more frequently in, a lot of multinational companies for example is, somebody's got their data in a country that has data residency requirements and they're not allowed to have an org strategy that would have their data in the USA if they're doing operations in Australia, for example.
There's also the, you know, in general, like, org limitations. So, that's more of a technical concern. So, if you're gonna be coming up against governor limits because your processes are so complex because you've got trying to gram everything into a single org, well, it might make sense to split that out into multiple orgs. And, you know, and then there's just in general like functionality and separation of duties, right? Like sometimes you find that your different departments, different divisions of an organization are doing things so differently that it almost doesn't even make sense. Like there's no overlap in their processes. The users are not the same users that are logging into multiple orgs.
I can tell you I did work for a multinational beverage company that was, that was like this at one time where they had, you know, the the customers that were in EMEA, they had their own sales and services teams. They never would see those teams, would never see the customers that were in the United States for example or South America or whatever. So every region ended up with its own separate org because there were also legal like laws and regulations that were different which then governed the way that they built their automations, governed their sales service marketing processes and everything. It just made sense to have multiple orgs and then roll everything up centrally for reporting to the executive level.
So. Yeah, absolutely. And there are some cases as well where we break apart a monolith and there are some cases as well where we are compelled to bring about a kind of multiple structure. So a different beverages company that I worked with actually similarly had this where they were choosing to have a North and South American entity for their business or rather US and Latin America, they kept.
And they did struggle quite a lot, I think, to kind of manage what that looked like in practice beyond the theory of, you know, having some coordination between the orgs but only a little bit of differentiation when in reality they needed quite a lot of flexibility.
I think and that's kind of a good point too that this slide, one of the things is it's never gonna really be cut and dry. So, when we looked at the last couple of slides and we have the, you know, here's the five reasons you choose a single org. Then the next slide, here's the five reasons you choose a multiple org or whatever.
More than likely, whatever your organization you're working with is somewhere in the middle and you're gonna have a mix of different factors that, some of them lean more towards a single org structure, some of them lean more towards multi org and what you can do is kind of put this scorecard together and think about things from just a business, a technical, just overall governance, how your organization is structured. And kinda give yourself a score and decide where do you fit. And if you're leaning more heavily towards a multi org side then that's, now you've got the scorecard you can bring back and bring it to your leadership because you're gonna at some point have to convince your leadership of why do we need three orgs instead of just one.
If you've got the data behind it to back it up, this is the type of information you can be gathering and putting together.
And then if you do decide that, you know, there's a bunch of different, operating models that you can have. So just dividing up and saying, hey, we're gonna have a multi org strategy.
Well, the next thing to think about is, well, great. Well, what actually goes in those orgs and how are those orgs going to work together to create one consistent overall view of your business? And we can see there's a few different models and they're based on complexity, how integrated you need your business processes to be, and then whether or not you are used to having your data siloed or replicated. So we can look at the different models, we can see that there's one that involves kind of coordinating between orbs and you're sharing your customer data. You've got different types of impacts on your department processes. If we look down on diversification, which is kind of the lower end of, you know, your business processes are not really integrated, you've got a bunch of just independent orgs with their own separate sets of customers, their own separate sets of processes that kind of fixed into what I was describing earlier.
Unification, this is more of the, okay, this makes more sense. Maybe everything goes in a single org or might be more than one org but they're very, very tightly integrated because you're sharing a lot of customers across departments.
You've got overlapping processes and you're making your IT decisions centrally. That's another thing that you're going to be weighing in on your factors of where do you choose, how do you choose your org strategy is as simple as do you have a central IT department for your organization and are they going to wanna manage multiple orgs or do you have, maybe it is a multinational company and every region has its own separate IT department that is okay with managing things locally. It's another thing to think about. Yeah.
And if you think about your business as well or businesses you've worked with in the past, you can kind of begin to plot where you might be on this. So, for example, if you're a global luxury goods manufacturer and you don't want to totally recreate your entire business model, but you do want to start doing business, for example, on an All Coast on Alibaba Cloud, you might want to replicate some things and you might want to coordinate other pieces of your work as well, you fit somewhere on that spectrum.
And so. Now, the one thing that, these last few slides that's funny because Claudia and I, we were talking about this when we were putting these slides together is, all of those last few slides we looked at are really nice when you have a perfectly greenfield environment and you're thinking from scratch about, do I need one org or do I need two or three? How many orgs do I need? The reality is, I'll tell you, a lot of customers that I've worked with have a multi org strategy either because through mergers and acquisitions they ended up acquiring a bunch of customers that already had their own orgs and there was not enough ROI to merge them together so they could set up.
We have multi org and let's just figure out how to integrate them. Or somebody did sit down and carefully think through their org strategy only to have an executive say, Yeah, but I want an org, my own org for my own department and that executive happens to have enough political clout within the organization that they are gonna get whatever they want and then you're stuck with a multi org strategy whether it's the best fit or not, right? So, you, there's scenarios like that where you're gonna find yourself with just dealing with multiple Salesforce orgs whether it's really the best solution or not and then the question becomes, okay, now how do we approach this, right?
And I think I'm guessing you've seen some similar situations.
Yeah, absolutely. And it comes from all different departments. It could be like an NGO who has to have fundraising organizations in different territories that are subject to different financial requirements, but the NGO themselves are subject to quite strict software development, kind of regulations that they're kind of subject to. There's also manufacturing, there's retail as well, trying to do business in different in different countries and handling customer data that they're subject to different requirements.
And there's also, obviously, as you say, the accidental multi org strategy as well. And classically, m and a as well. You know, you could acquire another business and with it, there's Salesforce. And now, you've got to figure out how to make those work together.
NGOs are another interesting one too because I was recently working with a, a for profit customer that had a division that was non profit.
And because of that, there were certain legal restrictions of, the for profit arm was not allowed to see certain data that the nonprofit arm worked with. So it was just easier to I mean, you can technically set up a bunch of security rules inside of Salesforce but it was actually easier to say no we're physically storing this data in a separate org and we're only gonna send the data that needs to be in the other org and that way we don't even have to worry about accidental access to it so.
Yeah.
And then once we kind of have put ourselves, whether through choice or not, on this path of MultiWork, we have a couple of different scenarios that we might be able to work through here. So the first one is to, if we have multiple logs, we maintain the same data model and metadata across orgs. We just essentially, we build something, we deploy it everywhere, and we just choose not to use certain parts of the org. We just duplicate the effort of deployment, but we unify the effort of build.
The second scenario is to set up two totally independent orgs and, you know, development pipelines and just to allow them to develop independently.
Ultimately, though, these are still the same business. And really, if you allow them to, offer independently and you get more orgs online, you're now multiplying the effort of building, testing, and deploying across how many orgs you manage. So the kind of Goldilocks solution here is scenario three, which is to maintain a common architecture that you can update and that the modifications in those orgs can depend upon, while also allowing those orgs to diversify and evolve independently according to the needs of the business units or region that they support.
I like this because, there's the org strategy part about like when you're thinking about data and processes. But DevOps, a lot of times people don't think about that right away of like, okay, now we've got all these orgs. How are we gonna keep things consistent? And how are we gonna manage development across them? So, yeah, this is great.
Yeah. And the the kind of classic way that you see it maybe not not happening so happily is, either you have a system where everything is multiplied in effort. So you just accept that everything has to be built multiple times but slightly differently, or you have the system where you just allow overrides to happen. And then every time there's a release, you just spend weeks bringing all your customizations back in, which isn't particularly delightful either. Right.
So there's various ways that people will have managed this and that you in the audience maybe have also managed things as well. And quick hands up for those of you who have used DIY CICD pipelines in the past to manage multi org strategy.
Yeah. Okay. Couple.
Managed packages, privately listed managed packages.
Yeah. Yeah. It's a little bit more unusual. And unlocked packages.
Yeah. So do you wanna talk a little bit about the pros and cons of these? Yeah.
So the DIY CICD pipelines, you could end up with, if you've got specific customizations across different orgs, you end up having to manually deploy things.
In a lot of cases, it can be challenging.
You're not really able to standardize on your DevOps processes if you do that. It really is DIY and then you end up having to keep making more and more changes to deal with all the customizations you have across your orgs.
Managed packages are great if you are an ISV partner and you wanna give somebody a package to install that they're gonna use your application that way. But if you're thinking internally, you could end up putting too many restrictions on the people that need to then make additional customizations to your org. And what we typically see is there'll be a central, you know, there'll be an effort to kinda control some of this stuff centrally and that's one of the reasons why organizations like to go with managed packages.
But then they'll have some local need because maybe something is a specific department that does something differently and they've got their own org for the reason that they've got a multi org scenario in the first place. Or certain part of the world that just has different regulations that they need to operate differently. And then people will install the managed packages that give you a nice baseline configuration.
And then because you can't go in and modify what's in the managed package, they end up doing a bunch of workarounds and localized customizations that make your orgs a lot more complex than they need to be.
And then unlock packages, they were actually meant to address some of the issues with managed packages but you still, it requires a specific skill set and I would say managed packages and unlocked packages both.
A lot of times you need a good packaging strategy to think about what are my baseline packages? What's gonna then sit on top of it? What are the dependencies between packages? Especially when you're thinking about managed packages that you basically need an architect to help you figure out how to handle all of those dependencies and the right way to deploy your packages. And not every organization has an architect that can be focused on just that specific task. So, the more you do work with those type of deployment strategies, the more complex it gets and then the more you find out you have people dedicating their time only to doing this type of work when they could be using it for other tasks that are higher business value.
I would say of the Manage Packages one, it is a little bit more unusual, but I think I know of two teams who are using it at the moment, one fairly successfully and one who are kind of beginning to attempt it. And it's driven by that desire to really lock down that kind of core architecture, especially when you're expanding out to more and more areas that you don't necessarily have oversight on.
Right. And it does give you that layer of control. So if you're working in a really heavily regulated industry, maybe it makes sense.
But we do see sometimes people will then try to figure out workarounds to get around with it.
They still want the extend ability.
Which kind of I guess brings us to the way that Gearset thinks about it. I think we can talk about that. Yeah.
So when we think about the way that we are looking at these problems, so we see the issues that we want to solve here in that we want to have control over the core, and we want to have extensibility and flexibility of the org specific components. And we don't want to multiply our build, test, and deployment effort. We don't want to make someone's entire job in to manage that process.
And we also want to have visibility as well.
And all of these kind of actually really do come under the umbrella of DIY. So when we were looking at the problem, we were approaching from the shape of how do we maintain that core control and how do we extend that out and be flexible. And actually the original kind of point at which we started thinking about this was when Salesforce launched Alibaba, Salesforce on Alibaba Cloud. Because suddenly, we had lots of people who never thought about multi org strategies and hadn't been on their radar, wanting to set up new orgs that were almost identical to their original one, but were integrated into the connected experiences gateway and were compliant. And then we're seeing more things recently pop up to people in Canada because they brought out their end data protection regulation.
North American companies doing business in Europe, being compliant with GDPR, and so on and so forth. So it's becoming more and more common.
And the way that we decided to look at it was how can we unify lots of different sources of metadata for multiple orgs into one core set of metadata? What is our core architecture that all of these share? How much can we bring that together and overlap them?
And then how can we layer that together with metadata, which is unique to an org, and then make that as a deployment to that organization?
Yeah. Yeah.
Which I will show you now. Okay.
Then we're going to talk about it.
I'll switch over here. And I'll give Tom control of this, the precious clicker.
So in the example that I'm going to show you here, ignore all of my screenshots, they are pretty poor.
What I'm going to do is I'm going to go to pipelinesgearsa dot com, and I'm going to open up my deployment pipeline. Now, the example I've taken here is based on a real customer that we're working with who are actually, funnily enough, one of the teams who's considering using managed packages. And I'm at the moment trying to say there might be an easy way to do that. So in this case, we have the Australian production organization, and we have the Germany production organization as well. We have changes which are developed, which are common to both specific to Australia and specific to Germany.
I have lots of changes which are waiting to go into either one of these organizations, core contact field, core new object. If you go to Australia, Australia new Apex Apex class. I'm not very imaginative with the way I named branches, I'm afraid, but you'll just have to imagine there's something clever there instead.
Now for Germany, what I've developed is a new layout and a new field, which is specific to Germany, but which references my core architecture, references triggers, classes, fields, objects, which exist in the core. And I just want to extend it out a little bit to make a new layout to let my users know whether or not someone's gone through a certain kind of financial regulation, which is very specific to Germany. So what I'm going to do is I'm going to pop that in. And if anyone wants to have a go at pronouncing this, please do have a go. Prizes to the best. But this is a very specific kind of German regulation here.
Sorry. That was horrible. My German teacher would be ashamed. And then what we do is we target Germany.
So the way that this works is we have modules within our repository. We have a core module which contains all of our shared architecture, and then we have org specific modules that we layer on top. And at the point of deployment, we combine them. So here, what I'm going to do is I'm going to commit to the Germany module.
Oh, you see that I tested this earlier. We're going to commit to the Germany module. And then what that is going to allow me to do is to see all of the metadata in that module and see whether or not it already belongs to core. So here is my new layout.
We see it doesn't belong to a module yet, or rather it does partially belong to the Germany module.
And if we look at the other components within here, we can see that this belongs to core. This belongs partially to core.
The dependencies here are two core fields as well as two brand new ones that I haven't committed yet, and that's what I'm going to do. I'm going to commit my brand new field and the layout updates specifically to the German module.
I'm going to skip this. I said this to Tom earlier. Nothing goes slower than a live demo with a loading screen. Perfect.
I'm not going to bother doing that. It'll be very naughty and move forward and continue to summary.
And then here we go. We have our target module, commit our changes.
And then what we do is we open a pull request and Gear Set validates that. And the point here is that I can now work as a member of my German specific team and create a pull request. Maybe I generate a description using AI to be really fancy.
And that is going to allow me to take core architecture, anything within the core, and add my own gem specific components on top of it in my own layered module, which is sectioned out from the core, keeping that discreet and specific.
Click UI is very much our bread and butter and is familiar to many, which means that when I Oh, I already created that for a request, didn't I? So when I create that, it's going to just pop up here, automatically validate, go through all of the normal code scanning, security, validation, merge conflict checks as we'd normally expect. And then when I'm ready, I can merge that into Germany.
So, this, the layering approach that you were, it's kind of, it's a similar concept to if you were to put together a really good packaging strategy but without having to use packages. And then you also get a little bit more flexibility about and then you get to centrally manage your deployments across all of your orgs and your landscape. So, yeah, that's pretty awesome.
It's it's not to kind of replace if someone's amazing with our modular packages or they found out a way to make a list of modular packages work, then Right. More part of them. But it's just not accessible to a lot of people.
So, the idea being here is that if we can flexibly layer these two things together, then we have enough visibility to make the flexibly layer these two things together, then we have enough visibility to make the correct architecture decisions for our business without having to wade through the technical aspects together.
Elliot, yeah. I mean, to your point, every one of those approaches has its pros as well. Like, there's there's reasons that all those approaches exist, but this is, it gives you kind of a nice way to pull some of the best parts from each approach and kinda combine them together as well. So.
Yeah. Awesome.
And, yeah.
Oh, it's the group. Okay. There we go. Okay. Which I think kind of brings us to our Q and A. I think we could probably talk and I know when we were prepping for this talk, we'd talk for probably hours about all the different people we've worked with and different multi org approaches we've seen.
Yes. And I think that for us chatting about it, it was really interesting to see there were kind of central motivators for a lot lot of people. But the way that the problem had been approached was so diverse from so many different people.
Yeah, I agree. Yeah, there are it's funny because I've for the variety of different industries I've worked with and the variety of different customers, you know, some in the same industry, some in different ones. I don't think I've ever seen two identical org strategies and everybody has their specific reasons for approaching things the way that they do or just the reason that things kind of evolved into what they are. But, yeah, it is interesting to see how diverse that is.
Nice. And then, I think that gives us time for our Q and A.
Yeah. We've got technically a minute, but we can hang out.
But we Who is the fastest talker in the room?
Raise your hand.
Otherwise, we and also we've got the happy hour afterwards.
Yeah, we'll be milling around for the rest of the day as well. But yeah.
Awesome. In that case, I think we're finished.
Thank you, everyone.
Hang on time. Thank you, everyone for coming.
