Mohith Shrivastava, who shares Salesforce managed package challenges, is a Salesforce MVP, 3-Salesforce-book Author, Lightning Champion, Trailhead TrailBlazer,20X Salesforce Certified, active contributor at stack overflow
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Main Points
- Mohith’s self-introduction
- Comparing developing solution for one org and creating Salesforce manage package
- How does the CPU governor limits impact ISV packages?
- How do other governor limits impact ISV packages?
- How do ISVs debug issues in the customer’s environment?
- What are the several fundamental ISV design principles according to Mohith?
- Namespace challenges
- 2nd Generation Packaging for both consulting firms and ISVs
Links
Video Teaser
Outro Music on Salesforce Managed Package
The Goonies – NES game music
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLellum. Here is reason number one that admins and users love this app. It's lightning smart. Admins can easily configure the one-to-one messenger component for private messaging, or collaborative team texting using queues or shared phone numbers. And using has record ID, the component always knows where it is, which conversations you want to see, and which people you might want to text. Proton Text uses Lightning Platform features and Apex logic to make the app intuitive and easy to use. It's not magic, just good design. Learn more at protontext.com.
[01:08] Hey everybody! This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I'm sitting with another great guest with me. His name is Mohit Shrivastava. Hello, Mohit. Hey, Shri. How are you? I'm good. I'm good. How about you? I'm doing good. Thank you. Thanks for the invite. Yeah, I know you have a lot of achievement in the ecosystem, but I still want you to introduce yourself first. Is that okay? Sure. Yes, sure. Hey, um, hey everyone. This is Mohit Shrivastava. I have been in Salesforce ecosystem for now almost eight and a half years. I am a certified system and application architect. I'm working towards my certified technical architect certification. I'm a Salesforce MVP. I'm a blogger and frequent contributor on SalesforceStackExchange.com. Also, I've authored three books. My last two books are one on Einstein for your Salesforce application, and the other is on learning how to build Lightning application using the Aura components. As I said, this is a great achievement. You touched different parts of the Salesforce platform. You know, you made even created a book for those stuff. This is just unbelievable, unbelievable. Thank you, thank you so much. Yeah, and you said you are going towards the CTA, right? Yes, yes, that's that's the aim, you know, to work
[02:38] towards the you know the certified technical architect. Great, great, yeah, good luck with that. Thank you. Yeah, today I invited you here to talk about the ISV coding, which means we create a managed package, we launch it in AppExchange, we release that, then we update the version for the AppExchange customers to download to install in their org. And I know that you have good experience on the consulting side, and you also have good experience on the ISV part, which makes you kind of unique. You know, most of people like me, I only did consulting. I have very little experience on the ISV. Yes. Yes. Sure. I have almost like three years of implementing Salesforce experience. Then you know, almost five years now, experience with building, designing, and solutioning ISV applications. And it's been an interesting journey actually building ISV applications because when you are actually designing for multiple orgs. It's a different challenge altogether than you know when you are actually working only a solution for a single org. Hmm. Yeah. Okay. So I only worked for a single org, and I know that if you create a managed package, you have to think more. You have to taking care of more aspects,
[04:09] right? Because your package is going to be distributed to a massive amount of customer org. It has to work. So there are unique challenges on on that side of the world. So yes, how how should we start? I think we should start with you know one of the biggest challenges that I see when you know when people are designing ISV applications they are not able to sort of scale you know in in Salesforce ecosystem. So I think we should start with that. One of the primary challenges is obviously the CPU time today in Salesforce. Because that's the only limit, Salesforce limit, that basically applies. You know, it's not it's shared limit. It's you know your code that already exists in the org, and the managed package code that runs. All share this limit. So let's say you have 10 milliseconds of the CPU limit time, right? Let's say you have a trigger on a lead, right? And let's say as an ISV application developer, you have added one more trigger, and let's say your client is already using. Nine milliseconds, and then you added your trigger, you know, which has some more logic, which let's say two milliseconds more, then you are breaking the Salesforce limits for your client, you know. And what it further does is, they are not able to sort of,
[05:40] you know, download more applications from an App Exchange which has some process around that same lead. Let's say you know there's a triggers there. Further packages which offer further triggers on the lead, right? So if those triggers are also not written properly in those packages, right? You will find that your client will uninstall all of those applications. You know, so yeah. So basically, there are CPU usage from your own package, and of course, the customer has their the code already deployed, and they might install some other managed package. So the CPU limit is shared on the three parties, right? Yes, exactly. So if it if it hits the governor limits, then you are failing. Yeah, and and honestly, sometimes it's like you know, it's not that the application is failing because as an ISV application, you might have designed it to you know to consume less CPU, let's say you know less CPU time, but then your client has some triggers you know on that specific context. You know they have poorly written, you know, so that also contributes to it. So most of the time it's like okay, and and also it is very difficult to CPU profile at that point because one of the and this is the second challenge that I'm going to talk about, you know, ISV applications is debugging. So once your package actually goes inside your customer's org, as you can see, even in the logs you cannot see what's going
[07:10] on. Like the debug logs, right? The logs are obstructed, basically, you know, or hidden for the managed package component. So today, if you have a managed package in your system, you will see that in your Apex logs or debug log. Sorry, let's call it debug log. In your debug log, you will see something like managed package entering and managed package exit. What happened in between that? Like how many cycles ran, or you know how many DMLs happened? All those information is not you know it's it's not shown by Salesforce, and that is because of the security reason. Because okay the Apex code of the package should be hidden. You know it's an intellectual property of the application developer basically at that point. Okay, let's back up a little bit. So you talked about the CPU governor limit. How about the memory governor limit? Is that also something you need to take into consideration? That's a that's a good question. Yes. So other limits, like for example, number of circles or number of emails, right? So a certified ISV application. Now I say certified because. You know every managed package application that goes on an App Exchange goes through a process called security review. That your actual you know the code that you put in your client org never goes through that process. It's specialized process called security review after your application. You go through that process. So Salesforce reviews it to find if there are
[08:40] any security holes in your package. It's a whole whole different conversation. Actually, there are a lot of things that Salesforce checks. So one of the things with ISV apps is you have to. You know, adhere to the CRUD FLS checks. Meaning, any DML that you do has to check for whether the user has CRUD access or the FLS access before the DML happens. Same thing for SOQL. Any SOQL that you write should actually, you know, adhere to the field level security that your administrators have set for the application. So, so that way, this is very different, right? The security review, because it goes through all the security reviews and checks, right? And now, when an application now, let's come back for your question. Like, what about the other limits, right? So a cert a certified package, meaning it has successfully passed through that security review process that I was talking about. What happens in in that is they get their own limits, meaning you know a namespace. So every managed package has a namespace. So in that namespace. I have the limit of hundred sockets. Now that's different limit. It's not going to be shared from your actual hundred socket limit. So that way you have the luxury of like your own limits for everything except that CPU. But eventually, eventually, if you have you know let's say a SOQL right, let's say you're querying like fifty thousand records and looping through right, eventually that's
[10:10] gonna be CPU you know even though we say there are shared limits right, what will happen? Eventually, somehow it is also impacting the CPU because all limits in Salesforce are equal from you know you can consider like that. That that part I understand because when I write in the customer code, which is not ISV code, if I store like hundreds of thousands of complex objects into the memory, then that will hit the governor limit as well. I don't know. Do you have such a same thing in the managed package? Yes. Okay. So that applies as well. Okay, that applies here, right? Yeah, so other challenge is you are building in an isolation. So these ISP applications, we don't have access to your customer org just like how you have for one org. You have sandbox where you actually build your application or code, right? But in ISP world, you know we just have to build it in our developer boxes. So it's usually all these things are not thought about data volumes. You don't think about if you don't think usually an architect should think about all those things. But if you don't think about let's say the data volume that your customers have, you might not even have an idea of what your customer has on let's say something like lead conversion or you know let's say you know an opportunity stage or an amount is sort of updated. What are the process they have? You have no idea, you know. So you are like
[11:40] building in a complete, you know, your own shell, and then all of a sudden, you know, after you deploy, you deploy into. An environment basically where you have no idea. Sometimes you discover that okay, this is something that it never stuck to me, right? So that's why having an experience of like you know, lot of building those application, understanding the architecture, you know, understanding Salesforce architecture in general about all these limits actually helps. Yeah, it certainly resonates with me. For me, I just need to satisfy one customer, and for a managed package, you have this that satisfies maybe hundred thousand customers. Some of them might just use some lighted records, right? Maybe hundreds of records, but maybe some customer uses really like millions of records. So that's a totally different story between these two customers. Right. Yeah, that that part I understand. And you just also mentioned the debug issue, right? I don't know. I don't know that it's it's hidden. That's debug information. So how do we even really debug? How do we help the customers who hit the issues? Yeah, it's so actually, I'll take it back that it is hidden. Yes, it is hidden. That is correct. But there is something called LMA. So LMA stands for License Management Application. So every every ISV customer or let's say ISV partner here,
[13:10] you know, because they are partner to Salesforce. So after they put their app on an App Exchange, they have their business org. Salesforce gives them a specialized org. We call it as Partner Business Org. So partner. So what happens in the Partner Business Org is. You have you have multiple applications installed there. One of the applications that Salesforce provides is called License Management Application LMA. So that application allows you to actually log into your customers and environment right from there. Provided your customer gives you access to that. So if you go to today, if you go to your org, you have something called as Grant Access. So in that grant access, you today can give you know if you have a managed package, you will also see that there is a grant access for that specific package. So you as an administrator of the application, you go and say, okay, I give the org access to this managed package developer for like three days or whatever days. Like maybe it could be one day, right? So when they provide you the access at that time. What happens is, from an LMA, I can log in and then, you know, I can collect some logs. I can see that, you know, logs there. Those logs are only related to your managed package, or is it all the logs from the customer? It is. It has all the logs from the customer. Okay, basically it's a dump from the customer, or again sent to you. Yeah,
[14:40] yeah, that's one way actually. And honestly, if you're architecting very well, right, you don't have to, you know, even think about like debugging later stage. But it does happen, you know, sometimes that we don't know there's a weird issue, and we want to look at that specific gap or specific problem the customers are having. But typically, what happens is we try to actually simulate or understand and do some. There's one type of testing we call it as load testing or LDV testing, large data volume testing, where we anticipate or let's say you are building. So that's one of the things like architecture when you are building an application architecture for an ISV. What there are fundamental principles. I call it fundamental principles because I've learned, you know, by failing a lot. So one of the fundamental principles is you try to avoid. As much as standard objects you can, unless and otherwise there is a specific business process need for that, because you don't know how your customers have sort of, you know, done things with those stuff. So you really try try to avoid it as much as possible. You know, that's that's the first principle. Try to not, you know, have a process designed or a business process around. Let's say you know lead object, lead is heavily customized or account or opportunity. Now if you are doing right, make sure to think about any trigger that you write on them. You know, just think through it. Is there a need for that trigger? You know, is that something
[16:11] that you can provide? Like for example, maybe a template for the client to themselves implement it. You know, sometimes solutions are like that. Maybe they already have a process like that, right? The other option is, can that trigger sort of go asynchronous? Because in asynchronous, you get a different limit. So those type of design thinkings you will have to do upfront, and especially now the custom object, right? You can extend it with a custom object. Now, if a package has its own custom object, there you are actually free because you know. You can put some rules around it, saying you know. So once it is a packaged object, you own it, right? So then, then you are you are very sure that your customers are not gonna be you know doing anything on that, right? Because you used it for your purpose. And then what you can do really is put some principles in place once your application is sort of deployed for the first time, saying this is you know or the limit or the boundary that we have already conceded with this. Object and before you put any process on top of those managed package objects, consult with us. You know if you're doing something with our objects, because admins and developers are sort of free to whatever in their in their environments, right? They can write some process builder that can kill that entire CPU limit, right? You know, on object. Let's say you provided an object called, you know,
[17:41] which is a lookup to an account. Let's say you provided your own order object. Now they went ahead and established some more integrations with that managed package, and you know, there are some more triggers or process on it, right? Yeah. So those type of things, then you'll have to recommend them certain things, you know, about what is the best practices when they are trying to implement a trigger on that specific, you know, object. This is very interesting. It's the first time for me to hear, as I never really used the ISV, is that when you create the managed package, you try to create an isolated object. Right. So you try to create the object that customer they don't touch usually. So only serves your managed package, and you do not try to touch the customer. They they frequently use the ones like accounts or leads, those things. They will create their customizations around. So if you have a clear boundary in between, then life is easier for both sides. Right. Yes. True. Okay. That is good. But sometimes you you just cannot avoid. Right. Maybe your package has to go through that. Yeah, that's that's true. Sometimes you cannot avoid it, and that's why we say you know, what is very important is to put a boundary around your entire solution. You know, meaning you have to. Put a boundary, like specifically. Okay, you have to imagine that. Okay, what happens after? Like, you know, let's say a customer has millions of cases. Let's say you are trying to put a process on
[19:11] case object, right? What happens when a customer has million cases? How does that gonna impact your entire thing, right? So every circle that you write inside your package, or inside your, let's say your manage package, you have to think through that query performance for that. If there is a custom field that you have created and if you're using it for the query, possibly index it so that you know your queries are more efficient at that point. I see those type of things. Sometimes, sometimes, as you said, it's not completely possible, right? And that's why one of the other things that I always think about is: okay, can we do this functionality from the UI without having to kind of You know, go through a trigger, or you know, use the whole CPU context. Like because if you have a custom component, like let's say you have some kind of an integration where you know your customer is filling something, right? In in that case, let's say you provide a component now with with the Lightning component architecture. That's one of the benefits that we are we're seeing as an I S V because we have access to quick actions. You can put your component so that the admins can drag it either as a sub tab or somewhere in the page, right? And then if you do that interaction through the UI, then you know you're probably not going to hit any limits from there because it's it's in a different context altogether.
[20:41] That's very cool. Thanks for sharing all this knowledge. You know, I need to be part of ISV company for couple years to learn these principles.
[21:00] Hey! Hey! Thanks for listening to the show. Salesforce Way podcast is all the time looking for both guests and topics. If you have guest recommendation or any topics you'd like to listen to, don't hesitate to let me know. My Twitter, LinkedIn, and email information is at the end of the show notes of each episode. You can also find it on the Salesforceway.com website. I really, really, really need help from you on this matter because only you, my lovely listeners, know what yourself want. So please help me invite great guests to talk on great topics, so that we spread great knowledge. Now let's get back to the show.
[21:56] Um, how about you? Also mentioned the namespaces, right? That's a mandatory action when you release your managed package. Does it affect something? I don't know. I have never really used the namespaces. It does affect a lot of things, actually. Not something. It does. Yeah, it does. It does affect a lot of things. So one of the things that was difficult, you know, and this is prior to Salesforce DX came. So one of the features that Salesforce DX sort of added was. You can create a scratch org with namespace now, so that's that's a very powerful feature. I feel that DX actually solved a lot of problems with that. But let let me talk about a bit before that thing, right? So before that thing, what happens is to build a managed package, you will have an org, right? And that org can have only one namespace. So for example, you choose a namespace called She, right? Now, you cannot create any other org with She namespace. It's unique. It's a unique. It's only one org, and there you are going to be packaging this managed package application, right? So let's say you referenced she underscore underscore and then your field name. What will happen is if you try to take that same code and put it in any other org than that packaged org, it's gonna fail. So that's why the principle. Now, you know, before DX we adopted this principle,
[23:26] and with the DX also, I think this principle still helps. So what we used to do is. We never used to hardcode namespace in the code, you know. No no field can be referenced with the namespace. It was always dynamic. You know there there there were dynamic patterns to get the namespace of the org. And if the org has namespace, then you know your code will dynamically sort of append it. Okay, so there was no concept of like static things, you know. So I was, it was very challenging actually because some of the things will not work, you know, with the yeah. One of things to remember is what used to happen is a lot of things Salesforce automatically namespaced for you. So, for example. As soon as let's say you write a query called select or let's say if you have a field on an account called let's say amount underscore underscore c. So let's say you write a query called select amount underscore underscore c from account. Let's imagine this is the query, although it's a very bad query, right? But let's say you write it and you as soon as you put the code in the packaging org. The moment somebody clicks the button to package this, Salesforce automatically sort of appends the namespace to it. You don't have to take care of it. Salesforce will automatically append that namespace. It will find out where exactly underscore underscore C is there, and it will automatically append it. Now the challenge with that was. Okay,
[24:57] Salesforce took care of it for a lot of things, you know, but did not sort of do a better job with other things. Like for example, when Aura components came up, you know, if you have referenced a field in the in your JavaScript bundle, it, you know, when you actually run this packaging process, it never used to go and you know append the namespace to it. Really, yeah. So your code might work in all the orgs, but then as soon as you develop, you know, package and deploy it, you will see that you know you're running into errors. So there are a lot of workarounds that you know we did it. For example, we wrote our own Apex wrapper layers for all the Apex that we are returning through the RI enabled method, and that way we don't have to deal with namespaces anymore in our JavaScript files because then. Since Apex can be namespace, right? All those will be automatically namespace when you run the the the packaging process. Okay, but how is it now? Do we still have this issue? Now we don't have this issue because now you know you can create a scratch org with namespace, so your developers can actually reference those namespace directly in the, in the code. Although one of the challenges that happens is what we have seen so far is what happens is let's say. You have built, you know, you have built an application or a product. Now there is a new company that acquired this, right? Now what they want to do is they want to merge this product into their product.
[26:28] So it's it becomes challenging then because then you'll have to change all the namespaces across all the files. You know because namespaces of the two companies are different, right? Yeah, and that's that's the advantage that we had in the previous method where we never used to hardcode the namespace. You know, it's all dynamic because then you can deploy it to any other org, compile and build it, and then put it into their package, and then it will automatically get namespace to the same namespace. Okay, interesting. Always this dynamic versus static thing for the namespace. Yeah. All right. And another thing I know is that now we have the second generation packaging, right? For the managed package, is still in beta as of today. And for the typical like a enterprise customers, we have the unlocked package, which we can already use. It's a in GA. So, how do you have any experience with the second generation package in terms of ISV? Yes, you know although I've not seen an ISV sort of completely adopting the 2G package yet, but I do have because of the you know my experience with you know asking lot of or basically customers asking me lot of questions. I had to sort of understand the you know the nuances of this 2G packages etc. The unlock packages etc. So one of the Now, unlock packages are really a great solution. I feel, but those. Can benefit both.
[27:59] You know, it can benefit your. Especially, it will benefit a consulting company. I'll tell you why. So, consulting companies usually work with multiple. Vendors, like let's say you're working with, you know, multiple companies. Assume one consulting company that has multiple clients. Now, let's say they want to build a solution. Which they don't want to put it on an AppExchange because putting on an AppExchange you have to go through security review process. There is an ISV agreement that you have to go through. There's a lot of things that you have to go through to put your app on an AppExchange because you're trying to sell that solution, right? But in consulting, you are selling your service, not your product. Right, so both are contractually very different. So for those companies, right, unlock packages are a nice way to sort of bundle that functionality, and then you can actually install in you know multiple orgs needing that solution. That's you don't have to go to the manage. Yeah, yeah. It's yeah. It's a it's a different thing. You don't have to go through the sec review and all those processes, right? It's a great for bundling. Today you can do that, but you need like a source control, right? Let's say you you know you're building a solution that you think is suitable for multiple clients. Then you need like a source control where you put everything. Then you need your deploy scripts to actually run and deploy, right? Yeah. But with this approach, it is very easier because then you can put it and then you can upgrade it also. So remember
[29:29] that with unmanaged packages, there was no upgrade capability. So once you deploy something, let's say you you patch some more bugs, then you had to actually deploy to the orgs. Imagine like thousands of orgs where you have you know put this solution and you you fixed something, then you have to deploy to thousands of orgs, right? You can't upgrade the package, but with unlocked packages, that gives you that ability. So I I. I kind of like the unlock packages approach. Very helpful for you know consulting companies. Also very helpful for ISV companies who have. Let's imagine there are some companies you know just for confidentiality sake. I won't name them, but they have very big packages. Meaning you know you install those packages and then you have to implement it. Meaning implementation means there are additional config that you do, and every customer has additional things. Let's say you have built a product, and then you know there are additional functionalities that you also have identified for your 50% of your customers, right? So unlock packages are great way to segregate them. That you build your managed package. And then other functionality which only some of your customers need, you can put it in like the unlocked package. So what happens is you give the core base package to everyone, but then if some people want some specific functionality, then you also give them that unlocked package where they can install it, and that can have workflows and other processes
[30:59] on top of those core thing that you have built. But just a question coming up is that if I use the Unlock Package as a add-on, then I cannot license the customer, right, with the Unlock Package. That is true, that is hundred percent true. You know, that yeah, you cannot license it. Now, if you need to license that, then that is where the extension package or feature management of Salesforce comes into picture. So there's a extension package concept where you can create an extension manage package, and that also you can publish on App Exchange. And you can sell it, sell it on top of your package, you know, as a bundle. And then there is a feature called feature management. So feature management are like, you know, they are specific toggles that you can change on and off from your license management application that I was talking earlier. So let's say your customer asks for X Y Z feature, you can use that feature management app to turn on and then change their pricing model based on that. Excellent, Mohith. I think I've used all your time, and it was a great lesson learned from you. You know about ISV. I hope one day I could have chance to really hands on ISV part. Let's have a chat next time. Thanks a lot.
[32:28] Okay. Thank you. Thank you.
