Adam Olshansky, who joins to talk about trigger framework, is Salesforce MVP, Salesforce Engineer at Google, 14X Certified and Pluralsight Author.
Main Points
- Adam’s self-introduction
- Adam’s Apex hours session – trigger framework
- Why do we need a trigger framework?
- How do we choose a suitable trigger framework?
- Why would we choose a sophisticated object-oriented complex trigger framework?
- Difference between teams working in one single org and teams from consulting firms in terms of choosing a trigger framework
- The feature that helps avoid recursion
- The importance of communication between admins and developers
- Create your own tailored trigger framework
- Using custom metadata types in trigger frameworks
- When shall developers start to study trigger frameworks?
Links
- Adam on Twitter
- Adam’s Apex hours session – trigger framework
- Adam’s personal site – Adam To Architect
Video Teaser on Trigger Framework
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:13] Hey everybody! This is Xi Xiao. This is yet another Salesforce Way podcast episode. Today I'm sitting with a guest. His name is Adam Olshansky. Hello, Adam. Hey Xi, how's it going? Pleasure to be here. Yeah, glad to have you on the show. Would you mind to introduce yourself? Yeah, for sure. So my name is Adam Olshansky. I'm a Salesforce developer at Google. 14 certifications, a Salesforce MVP. And I love talking about code and Salesforce development. Yeah, it's really great to have you. I understand you had a session in the Apex hours for the listeners who haven't watched that. It's a video screencasting sessions, right? Over there, you're talking about how to write a trigger framework or how to use those famous trigger frameworks, and from the simpler ones to more sophisticated trigger frameworks. Yeah. So I. I was able to presented Apex hours this past year. Um, there was a YouTube video about it. Just going through a couple different options for trigger frameworks. We walked through the code, pros and cons of each, and and how trigger frameworks can help you become a better developer and control your code. But over there, because it's a screencasting, so you have going into a lot of details into the coding part, right? You showed those codes. What does it mean? How you write those code, and what are the patterns behind those trigger frameworks?
[01:39] Yeah, yeah, exactly. So we were able to walk through the code, see some code on screen, demo it, things like that, and so it was was kind of nice to see, but. A little bit different medium today. Yep. So I will put the link to that session to our show notes, so for our listeners to check. But here today, I want you to be on the show. Is mainly to talk about like the why and how things around the trigger topic. You know, as a Salesforce developer, trigger context is definitely one of the most important things we need to know, right? A lot of things are kind of beyond the expectation. When I was joining Salesforce, I know the trigger framework, but I didn't know it was so like a rabbit hole you can dig into that, and that get a lot of surprises out of that. Yeah, definitely, it's very easy to to get lost going down in there, and and there's no one right answer. It's the other thing, a lot of different ways to do it, depending on your your use cases. When I was a junior developer, so I started to use the you know some coding around the trigger context. But I didn't know it was that complex. There are a lot of things I need to take into consideration, especially at the beginning of the everything. So that's why I wanted to talk to you about this topic here. Yeah, it's definitely a lot to take in, especially
[03:09] when you're just starting out, and especially if you kind of start looking at an existing built-out trigger framework and and don't know how all the pieces fit together. A lot of different. Nuance and and differences within frameworks across companies. Let's start from some basic things. So, in Salesforce, we have the trigger context, but it's still option of us to use any existing trigger frameworks. So, why do we need to think about the trigger frameworks?
[03:40] Sure. So if we think back to like triggers in general, right? You know, very basic principles. We don't want to put trigger logic in the trigger itself. So we might use a trigger handler. You know, if one of the other principles of code is not wanting to have to repeat ourselves, right? And so if we have all of our triggers with. You know, check for if before insert go to the before insert handler. If after insert go to the after insert handler. We have to do essentially the same code in every single trigger, and there's a lot of repetitiveness. And so the nice thing about a framework is it kind of gives us the option to handle the routing for us. So we just have to code it once, and the framework handles it the rest of the time. Our triggers can all be one line long. Just call the trigger framework. The trigger framework can figure out the context, can figure out what object we're using, and can figure out what class we need to route to to continue our our execution. Hmm. Because I understand in your videos you have mentioned multiple trigger frameworks. So, as the people who start to learn about these things, so which ones should I really choose from? Is there any like a guidance on this? Sure. Um. So I start off talking about uh kind of three different frameworks in the video. Uh, the first one kind of uses a virtual or a class with a bunch of virtual methods. So it lets you pick and choose what you want to override in your handler. It has a single run method
[05:11] that'll take the context and route you to the right location, and then in your individual handlers, like you know, lead trigger handler for example, you can choose to implement handle before insert, handle after insert, things like that. Another one might be an interface that again will predefine all the before insert, after insert things like that, and then you'll have a trigger handler. And a trigger dispatcher that'll route to the trigger handler. Inherit from the interface, and then you need to implement all the methods. But again, you can rest assured that every handler is going to look the same. And then the other approach I talk about is more of a full blown object oriented architecture, where you have a trigger factory that constructs a dispatcher that constructs a base class, and then you have each handler as an individual file. So you'll have an account before insert trigger handler, account after insert trigger handler, and that'll then inherit from another base class, which takes from a trigger handler, and you get kind of a combination. A virtual interface approach, which may be too much for for some of the more basic use cases, but if you have a very complex org, it can be very helpful to. Kind of get a handle on all that, and again, you just have to implement it once, and then it works the same for everything the rest of the time. The the last one you just mentioned that this full blown object oriented design just for the trigger frameworks, it sounds really sophisticated, and it will take some time
[06:41] for us to digest that. Right? Why do we use this, and and and what's what's the benefit using that out of this framework? So usually, a argument coming out from the people around me is that why should I do that? Why should I spend a lot of time to learn this? And there there are some simpler trigger frameworks like the first two ones you just mentioned. Maybe it has just a virtual class or like an interface, right? You can inherit it from that, and then that's almost everything from the frameworks. Yeah. So a couple reasons. One of them, I'd say, more complex use cases. It can be helpful because when you are getting you know farther and farther along in your org and adding more and more code. You know your handler. If you just have a single handler, which is what the other frameworks generally rely on, it can get pretty robust, right? You might have a hundred lines just for before insert. You might have another hundred lines for after insert. Before you know it, you have a five hundred thousand line class that's getting a little unwieldy. So the more object-oriented architecture focuses on each event is for each object is going to have its own class. Number one, number two is is like I also mentioned it kind of combines the virtual and interface approach, where you know in one case you can inherit from. An interface you're going to have the capability, uh, to call whichever class you want, but at the same time you'll have the virtual approach where you can pick and choose,
[08:12] um, how you want to use it, and so it it allows for more for nuance and more customization, um, and and kind of the same thing with Salesforce, right? The The fewer customization options there are, the easier it is to use. With the more limited you are in what you can do with it. With this object-oriented architecture, it's complex to use, but there's a ton of customization. And so, if you have a really complex use case, you can tweak it accordingly to make it fit your exact needs. Okay, so there's no a silver bullet answer here. You just need to, according to your situation and your skill level and the context, to decide which one to start with.
[08:50] Yeah, and and as with most things with Salesforce, right? There's multiple ways to to do the same thing. Um, I remember the first time I started using it, I came into an org with a full blown trigger framework, and I remember it took me like ten different tries or ten different steps to figure out where the code actually was that I wanted to debug. Yeah. Um, so it can it definitely be very. Hard to wrap your head around. It's still a little hard for me to wrap my head around sometimes. But sometimes that's that's the right decision if you do have some very complex use cases. So Adam, I understand you are currently working in Google, right? So I would assume that you are working for an internal work and internal product. So it might be easier for your team to decide, like one trigger framework for all the teammates to to use.
[09:41] Yeah, so that's that's I think two things on that topic. One, yeah, it is easier when you're working on a single org, and you can decide as a team. The other thing is you have to make sure there's kind of full buy-in from the team because it kind of defeats the purpose of the framework. As one object is using it, another object isn't. And I've seen that before, also where okay opportunities use the framework, and then leads are kind of doing their own thing. So that kind of defeats the purpose. You go through this whole trouble of setting up this robust framework, and then it's only getting used by one object. So true. Okay. Yeah, definitely something to to keep an eye on. So once the decision is made, then everybody should follow that strictly on all the objects, right?
[10:24] Yeah, agreed, and and that's why sometimes it's it's easier if a little easier if you're a a consultant or or you're starting out with a new org to kind of implement it at the beginning. It's much harder to take an org that's been around for months or years and say, hey, we're going to refactor everything and and shove it into a framework. Yeah. Actually, I am working a consulting firm, and to make everybody agree upon one or handful trigger framework, it's a really challenging task here. So people definitely have different opinions. Even after studying for hours and have a conversation for hours, still, we we can't come up with the idea on which trigger framework to use. And finally, we just decided. Okay, so maybe trigger framework it's important, but still more important for people to understand why to use that and what kind of patterns are adapted in the trigger framework. So that even if you don't use any trigger framework for a simple work solution, still the code is manageable. It's still scalable in a sense. Yeah, yeah, I I'd agree with that, and and I think in some cases a trigger framework is the wrong option. If you do have some very basic use cases, and your trigger framework ends up being more code than the actual trigger logic itself, it may not necessarily make sense to to have it, you know, go to five different files, ten different files for a ten line block of code, right? Yeah.
[11:54] But it's just so difficult to make the shift later on, especially in the real life. There could be different teams working on the solutions, and then when to make the shift—that's really a question. And a lot of time, people just tend to follow the old design. Right? If things are not broken, then why should you make the shift? And then the technique debt piled up, and then one day you really wonder: Is it even feasible to make the shift? And now it didn't work.
[12:28] Yeah, that's a fair question. It's it's always a hard discussion to say. Hey, I'm gonna stop working on new features and clean up the code. You're not gonna notice a difference, but I promise you, I'm doing good work. So yeah, it's definitely it's harder to do to down the road for sure. Yeah. So. I have some questions around the trigger. Those are like typical challenges or problems, and I wonder if any trigger framework can really solve those problems. So, for example. We have the declarative tools, right? We have the Process Builder, we have the workflows. So sometimes those declarative tools will make the recursion in the trigger context, right? Everything is around at the end, and the declarative tools will update another field. Then the trigger context go back to the beginning, so recursion is happening. I wonder if the trigger frameworks are able to handle these kind of situations.
[13:33] Yeah, definitely. So one of the the other nice things about frameworks in general, you build something once and you can use it for everything. So with the trigger frameworks I talked about in in Apex hours, even there are some different options. One of them in kind of the The main trigger factory or trigger dispatcher class. You can build in some bypass capabilities that you can use along with each trigger. There's another approach I talk about where you have custom settings or custom metadata where you can just toggle an entire part of the framework on or off. So maybe you want to turn it off for the contact object or loading a bunch of contacts. Things like that, and then also recursion checks. So we have static variables that say, "Hey, has this code run already for this transaction?" Or even you can go one step further and say, "The first time this code runs for this transaction, I want you to do this stuff. The second time this code runs for this transaction, I want you to do a whole different set of stuff." And so you can route it accordingly there within the context of the framework. Okay, a lot of time we don't have a trigger framework, so it's really difficult for us to handle this kind of situation. And those declarative tools, they are, you know, most of the time they are implemented by admins. So it can come any time, and then when the recursion happens, then you just kind of passively to look into the code, and then you realize, okay, it come back again for for this reasons. Especially with how how powerful the
[15:03] the declarative tools are becoming, I know flows are becoming a big factor as well. It's definitely important to make sure that the code and the declarative tools are working very well together. And I still think that the the communications between developers and admins should be smooth and seamless. Here, right. Exactly. Yeah. One side, it would definitely break the things on the other side. And if we communicate and talk with each other when we make changes, then probably it's better than the passive ways that we're doing. Yeah, frameworks aren't going to solve a communication problem for sure. So that's that's going to be probably the most important thing that the declarative and the non-declarative sides of the platform are communicating well, and and the people implementing the both sides the platform are are on the same page too. Okay. Another challenge that I usually see in my working experience is that when the code enters, for example, account trigger context, and then at some point we update a related contact, which will go into the contact trigger context. So it's kind of like not in an isolated way; the things are entangled one with another. So how would the trigger framework be able to really tackle these kind of problems?
[16:32] Sure. So I'd say probably there are a couple different approaches. Number one is you could have something in the, for example, in your example, I think it was lead. You know, lead is the one that started things off. When we're updating, creating contacts, before we do that, we can just shut off the contact framework altogether and say, hey, I'm creating contacts as part of the lead framework, but I don't want any of my contact code to run. Uh, alternatively, we can implement the framework in a way that says that the contact framework will know, hey, yes, I'm running, but the lead trigger is what called me, and so I want to, you know, run a separate block of code than if the contact was kind of the primary object and was the initiator. So there's a couple different ways to handle that. Again, depending on our our use cases. Okay, and not all the trigger framework have these features out of the box.
[17:27] I mean, yes and no, right? I think the examples I walked through, no, but one of the things I talk about also is you can always mix and match. So if you like something from one framework. Steal it and put it in your framework. So you can. There is no kind of set definition for a framework. It's more kind of approach based, and you can kind of pick and choose. Okay, I want to use an interface. I want to use virtual classes. I want to have a bypass. I want to take from custom settings. I want to toggle on it on and off. I want to have a recursion check. So kind of, again, what works best for you, kind of put it all together and and implement a framework that'll meet your needs. Does that mean that if I really want to learn this topic well, I should implement my own trigger framework?
[18:15] I mean, I I don't know if I'd recommend reinventing the wheel necessarily, but it's definitely a good way to learn, if not necessarily a a good in. In in the working world, but definitely a good way to learn, and and I'm sure, whatever framework you end up coming up with on your own could potentially be useful. In projects that you work on down the road, you know one of the most the famous customized the trigger frameworks in my company is just as you mentioned. It's like picking up the different features from the multiple trigger frameworks and then combine them into one. And nowadays, I think after the custom metadata types is life. I think a lot of trigger framework are moving to that direction as well, using the custom metadata types to control a lot of things dynamically. So, so it's like all the new features we try to use it into the framework and see how it works.
[19:16] Yeah, I'm. I'm definitely a huge fan and proponent of of custom metadata types. So I'm. I'm definitely all for implementing those and and integrating those with your triggers, and it makes it very easy if you just want to shut a framework off for a few minutes. Um or if an admin's doing a data load and wants to shut the framework off for a few minutes, custom metadata and custom settings make it very easy to do that. Okay, so in the past we had the a topic about my triggers. It heavily uses the custom metadata types, which it's okay. It's quite uh interesting. The thing is that when I look into the code, it's open source the framework. So looking the code, it's quite generic. I think. It takes a lot of time for me to understand what's going on, so I would assume for other junior developers, it also it's kind of difficult. You know, it's more generic using the S object ways to cast here and cast there, so it's not the typical static code as like a enterprise developers would use. So just one caveat about that. Yeah, and and I think that's probably a general. Thing as well. The more generic it is, the more customization and the more diverse ways you can potentially use it. But also the harder it is potentially to understand. Also, so you get kind of the have to weigh the pros and cons. But but agree for junior developers and sometimes even myself, it can be uh. Hard to walk through the first time around.
[20:46] It takes a couple passes, and a diagram can definitely help figure out, right, what's really happening here. Where is the code going when my lead gets updated, and how does it end up going from here to there, to there, to there, all the way to there? So, yeah, yeah, good to know that you also spend a lot of time to learn triggers and learn trigger frameworks. I think you get a lot of benefit and learning experience out of that, right? Yeah, but for the juniors like me, or even like really new to the Salesforce, do you think it's important for them to pick up the trigger frameworks early, or should they just focus on some like patterns, so like some important patterns? Which is I don't know which which way do you think they should go to?
[21:40] Um, I would probably say always building um up to things is is probably the better approach. So depending on where you are, kind of in your your journey, starting off understanding, all right, what is a trigger? Right, why do I only want one trigger per object? Why do I maybe not want to put my logic in the trigger? Put it in the handler. Why am I writing the same code in all of my triggers? Why am I writing similar code in all of my handlers? Is there a way I can abstract that out and so kind of build up to it? Maybe start with a more basic framework, understand how that works, and and work your way up to a more complex one. But again, it also depends on you know who is your customer, who is your client. Are you working with? A very basic org that doesn't need too much customization. Are you working with a full blown org that's been around ten years and has a ton of code and a bunch of triggers per object, and I really need something to corral it all? So it it kind of depends. I definitely wouldn't recommend just deep diving into frameworks, but at the same time, it does kind of really depend on on what your customers' needs are. So my experience is that really looking to some of the famous ones to see the differences, and then try to understand why they're picking the different routes, and what the benefit, pros and cons. Because the things that as a developer the time is limited, so you are working on couple of projects.
[23:11] You can't meet all the different situations or the things that are using the trigger framework. But by learning those famous frameworks, you start to you know standing on their shoulder. You understand okay these things might happen in the future and are important. So I I should learn it.
[23:30] Yeah, agree, and even if you don't understand exactly what they're doing, understanding that they exist, what their capabilities are, knowing that they're out there, and at some point down the road, you may encounter a situation where, hey, this is what I need to do. Maybe a framework, this framework or that framework, could be helpful to me, and kind of take a really deep dive when the use case comes up. But but definitely understanding the capabilities, I think, is almost if not more important than understanding the code itself, because if you Implement the wrong one, then it may not be as helpful to you, even if you understand it very well. Excellent, thanks, Adam. I think that's all I want to ask you. Thanks for your time, and I still recommend our listeners to to watch the videos because there you talked a lot about the famous trigger framework under the hood. Yeah, and I have examples to go there too. All right, thank you so much, Xi, for having me. Yeah. Thanks. I have to talk
[24:33] to you next time. Bye bye.
