Christian Szandor Knapp is the head of Salesforce Development at Appero, Salesforce MVP, Co-Leader of the Munich Developer User Group.
Szandor is very passionate about Salesforce technology.
Main Points
- Why does Appero release yet another new trigger framework?
- What benefits does MyTriggers trigger framework offer?
- How does MyTriggers leverage Custom Metadata Type to control the trigger logic flow?
- Discussion on existing trigger frameworks and their pros and cons comparing to MyTriggers.
- Discussion on how to select a proper trigger framework according to time investment and current programming skills
- MyTriggers also supports platform event
Links
- MyTriggers GitHub repo
- Szandor’s blog
- Szandor’s twitter
- Dreamforce Video – Route your triggers like a pro
- Don Robins’ and Dan Appleman’s trigger pattern play-by-play video
Video Teaser
My Takeaway for Trigger Framework – MyTriggers
After custom metadata type is released, not only Salesforce applications start to use it for app configuration but also trigger frameworks use it to control the trigger logic.
If you have listened to Szandor’s talk, you will see that MyTriggers trigger framework is one of those heavily leveraging custom metadata type.
One of the biggest features in MyTriggers is that it uses custom metadata type to control and visualize the trigger logic so that admins and business users could also understand the logic without checking the code.
In my opinion, regardless of which trigger framework do we pick up, it is more important to understand what features the selected framework supports and how it was implemented by looking into the code. You could check this play-by-play to learn from experts Dan Appleman and Don Robins :).
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] Hey! Thanks for tuning to the Salesforce Way podcast. In this episode, I sit with Christian Szandor Knapp. The company he's working in has open sourced a new trigger framework called My Trigger. Yes, yes, yes. I know, I know. There are already trigger frameworks out there in the open source world. Why do you guys create a new one, right? I asked the same question during our conversation, and actually, his answer has convinced me. This my trigger is a good thing. It has brought. Extra value to the ecosystem, and it has got me thinking about the new paradigm shifting in the Salesforce platform. So, with that said, let's listen to the conversation.
[00:57] Hey, everybody! This is Xi Xiao. Listen to yet another episode of Salesforce Way Podcast. Today I'm sitting with Christian Sandor Knapp, right? Long name. So how how would you like call your name? Should I call you? Sandor. Christian Sandor. Say Sandor. Sandor. Okay, cool. So Sandor. So welcome to the show today. Thank you for having me. I'm really nervous because this is my first podcast ever. It's cool. Okay, we will also release the video maybe in future. Then it's not the podcast. So before we jump into our topic, would you still want to introduce yourself? Yes, certainly. Hello. As she already mentioned, my name is Christian Szandor Knapp. I usually go by Sandor. I work for Appero, which is an ISV based in Munich, Germany. We're one among the oldest ISVs in Germany. And have our stuff on AppExchange, namely a nice and very very very very very very very very very very very very nice solution for quotations. That's because we redid it completely in Aura components because that was the choice. We had it running in Flex, which is a Flash technology, but we rebuilt everything from scratch in Aura components, and we're really, really proud. Or we actually are. Actually, yeah, we're proud. We're proud to have done that. Okay, I get it. I get it. So
[02:27] I invited you mainly because I watched your Dreamforce talk. I really love it's what you and Daniel together, right? Yes, you both are from from Germany, and you made the topic. It's called the the trigger framework or how to use the trigger framework, something like that. Root your triggers like a pro. For streamforce, it always needs to be a fancy title. Yeah, I will put that video link down below in our show notes just for our listeners. But I understand you have studied a lot about the trigger and the trigger framework, how to use it, what's the importance, and you know those those kind of hints for for people. So that's the exact reason I want to get you in here. And you know, it's like understanding from my point of view. Have been in the Salesforce for about two years. So the first two things I learned from day one. One is do not put your circle in the loop. Yes, and the second one is really how to do a trigger. So the trigger framework or trigger pattern is something what we always try to you know to implement. But the challenge now we go to the challenge. The challenge is that there are too many trigger frameworks in the internet. Everybody reinvent the wheel and they say, okay, this is important and this is the extra feature we want to do that. So for us, for the beginners, it's hard. There's the selection difficulty for
[03:57] us. So which one fits us? And it's not easy to learn those framework. You know, there are interfaces, there are kind of different factory patterns, there like a dependency injections. There are a lot of fancy words. Not in hours. Not in yours. Okay, I watched it. At least not at least not on on on the surface. So if you are implementing it, it's very straightforward. You don't need to know a lot. You just need to copy a little bit of boilerplate code. But that's always the case with any framework.
[04:31] Okay, so let me ask you a question by giving an example. So let's assume we have a medium-sized Salesforce business work, which contains about 120 business events. Why is 120? Don't ask me. But assume that's a medium-sized business work, and how could your my trigger framework help this business do better control their work? If you go down the full path and say, okay, I have 120 business events, which is not a lot for for a decent sized company. So, how do I maintain them? How do I explain people what they do? How do you document this? And there comes the idea of trigger framework, right? So and the idea of the trigger framework for me and for my triggers was not so much to to build yet another framework. Okay. The goal for me was visualize the stuff that is happening in your work with triggers. And there's lots of lots of different nice to have side effects as soon as you start to use custom metadata records. So basically, okay, each record says, please run this class. That's that's first of all everything they do in the my trigger framework with and by those metadata records you control should the trigger run or should not the trigger should the functionality
[06:01] run or should it not run. And you have several ways of deciding when it should run because each record offers you tick boxes for before insert, after insert, and so on and so on and so on. We're currently working on better UI for those custom metadata records, lightning based, in order to give you and your administrators or anyone coming into an org an immediate idea what is happening. So you see a list in your org. Okay, on the account object, I have four trigger handlers. Two of those work on after update. One of those works on before delete. One of those works on before insert. And if you go into New York, and there is no trigger framework that uses custom metadata records or anything else that is data in New York, you will need to look up each trigger to find out when does it run, for which records, and what situations. And that's something you could ingest. In a glance, by just looking at a custom metadata table. Now, if you think back about. the The idea of building an org more to the business needs and decouple everything else and have less less trouble with with consecutive triggers. Okay, if if we use something like the my triggers framework and we say okay, we have let's. Call it business event, new customer. Okay, for
[07:31] every business, there's probably something that needs to be done if a new customer joins the lucky family of many, many happy other customers. And in the traditional trigger sense, it would be okay. I have account trigger, and if the account type is new customer, I do something, right? And then some some updates happen, and at the end of the day, I also need to update a case, and that's a specific onboarding case for for this customer, and then I'm done, okay. In the traditional paradigm, you would then see as executing classes something like account trigger handler, and then case trigger handler or contact trigger handler, and and and the maybe a little bit too bold a vision I'm envisioning. It's because at the end of the day, those are all things that happen because I have a business event, new customer. And not because in the Salesforce world there happens to be a close connection between account, contact, and case. And if I want to go with a new customer in the CRM, I usually do all three, do inserts or updates on all three contacts. Right and from from from now, just look at the table. You would not see three different handlers and which tell you nothing because they just handle contacts or handle account. You would see okay if we have the event or a new customer or something happens that or when an account is updated,
[09:01] then we have a logic that checks. Is anything to do for a new customer business process, or is there anything to do for the closed opportunity or closed deal process? And so you you have it business specific and business centric in in your visualization instead of as object or CRM centric. Hmm. Okay, I got you. I got your point. So you want still create a visualization that allow the business user or the people who do not write code to really go to that visualization, either a diagram or maybe a table. It's a table, currently. Yes. Yeah, it's a custom data table, then it's a table to see when something happens on certain object. Then yeah, a class would get the. Execute it, and that class has a name, which maybe it's a clean name that the business can understand. Absolutely, and that encapsulates all these internal logic, like trigger on different objects or those executions. Yeah, exactly. So imagine if if you if you're trying to understand the business, you you look at the new customer process, and you don't look at okay, there's a contact trigger handler, and an account trigger handler, and a case trigger handler. Which do not couple stuff according to business needs, but according to the object, right? So a case service is around case methods.
[10:32] It's not about different business processes that leverage the case object to get their job done. I get the point. I get the point. Are you the first one? Coming up with this idea with the custom metadata for the kind of abstract extra layer. No, the idea isn't new at all. So when we built my trigger, we didn't build it from scratch either. There was already a trigger framework around called TriggerX by Sebastian Wagner, who used to work for Tequila, I believe. I did a lot of research on what kind of frameworks are out there. And if I like them or I do not like them, we don't need to go into details why I dislike or like something or the other. But at the end of the day, I found trigger X, and that was lightweight and with little boilerplate code and really really fancy in the way that, for example, within a trigger execution, you can tell another trigger not to run. Hmm. Okay. I see from your Dreamforce talk, you also mentioned this as a one example. Yeah. So for example, I know that I'm I I am now the account handler. I know I will be inserting a lot of contacts. I know those contacts are perfect. They don't need validation. They don't need any other trigger handling. I do that all on myself. So I will will tell the contact trigger on runtime.
[12:03] Please do not run. Okay, that's another feature that TriggerX came with, and one of the things that it lacked were were two things. It was pretty dated. Not in the sense of code or cleanly less, but in the sense of API version, and in the sense of that they use custom settings to control a little bit. And we took those custom settings and we worked them into custom metadata records, added some more functionality around. And one major difference to trigger X in comparison to my triggers is that my triggers can work with different namespaces. So for that, you need to envision an org of the future where we have unlocked packages, lots of unlocked packages, and those are all namespace. Now you have one part of package that deals with the account, and you have several other packages that deal with the account. And if they bring their individual account triggers, then you have the issue with the you don't know when which trigger will run. Then you will need something to tell the triggers in which order to run. And what my trigger can do is work with classes from
[13:25] distinct namespaces. So if every ISV would implement my trigger today. Tomorrow, each customer could activate, deactivate, or change the running triggers of managed packages or ISV package any way they want. Hmm. Okay. I I see the power of the granular control from the custom metadata from this framework. Yeah. Since we're an ISV, we also thought about unlock packages and unlock namespace packages, and all kinds of situations. And our idea is, if possible, the customer should be able to control trigger execution. This comes at a price for for data integrity issues, but there's so many use cases where you need an exception or this and that and that, and we will have in in my triggers soonish check boxes for do not run if a custom permission is on the user or do not run for certain conditions. Yeah. So in order to also configure. Your exceptions there, and that's also triggers if they're implemented do a great job in being inflexible, and that is their job. It is their job to guard data and the state of the data and the consistency. But there's still issues where we want to migrate maybe not so perfect data for whatever reasons. Not that I endorse pumping not so great data into your business org, but. It's your call, right? And for that, you might have the need to deactivate
[14:55] triggers. And if you do that without a framework or any kind of wizardry, that means deployments. So you need to go to the change block, deactivate all triggers, deploy them to production, and make sure your tests are still not failing. Because that's the issue, you know. You deploy fresh code, so your tests will run. If your tests rely on the presence or the active trigger, your tests will fail. Will not be able to deploy to to production. Yeah.
[15:26] Hi,
[15:31] here's a quick note. Don't forget to check the show notes of this episode, where you can find short video teasers, the guest contact information, the important complementary materials, and my own learning points, among many other useful information. In addition, I have also started a YouTube channel to share important stuff I learned from my guest. If you are serious about your Salesforce developer journey, you should definitely consider subscribing to this channel. And obviously, the name of this YouTube channel is Salesforce Way. Now let's get back to the show, shall we?
[16:21] Thanks for letting me know the the features from this my trigger. I think it's open sourced from Apereo, right? From your company, and definitely the companies using this trigger framework. We are your managed packages. So and gladly not we're not the only ones. There are a few fans out there. Okay, that's cool. I mean. So now I want to just put myself into the shoes because I'm doing the consulting business. It's in a totally different world than the the ISV is. So for me, a lot of fancy features I just never experience for whatever reason I don't know. And how do I start? Still, you did not solve my problem. Which one to pick from? I know your trigger framework has good features. But, but it's so powerful. It's so heavy for me, and there's no way for me to convince. We will everybody from our company when we do consulting business. We will go from a pure trigger from work. You should. You should. I understand. So, I think it it is worth investing how you can get from very simplistic triggers and with little little effort to something pretty decent. Without going the full framework thing, and if you're interested in that, there's a brilliant course by Dan Appleman and Don Robbins on Pluralsight, which talks about trigger patterns. And basically, Dan teaches us how
[17:51] to go from a pretty simple trigger into a more sophisticated trigger within 20 minutes without too much hassle. And that's the invitation for customers, to to also think think about their standards and also think a little bit about their needs. And needs are something that develop. And sometimes you can't you don't have a little crystal ball, so you can't look into the future and tell yourself in two years or in half a year I will have that need. If you're small enough, you use a few trigger patterns. You have five to six triggers, all good. That's it, no need for a framework. But as soon as it gets more complex, then you should start investing on which trigger framework fits my needs. Too late. No, it no, it's not too late. As if you adhere to certain patterns, because if you have the patterns, then it will be not immediate, but with not so much work possible to implement a framework. Yes, you will need to rewrite certain Apex classes and so on. But if you adopt the pattern of not putting your business logic into a trigger itself, you're already halfway there to a trigger framework later on. But if you have all your business logic within a trigger, then you will have to do a lot more clean up. I get your point. I just want to challenge this idea. Why not? I just you learn one
[19:21] trigger framework very well, and I use that from day one, and then no matter the business will grow or not, I always use that trigger framework. So it's not a good idea. It is an idea if if you are happy with the invest. So the invest me understanding the understanding or also the issues that you might be having. So we are having an issue with the my triggers framework, for example. So in order to say which records runs for which object or is responsible for which objects, we use a picklist of type entity definition. That is a certain type of custom metadata records. Which basically lets you link to existing objects in your Salesforce org, so not to records, but to objects. So I can put their account in there, and that's a feature, a great feature of custom metadata types. But we found that a lot of standard objects are not supported. So, for example, tasks, activities, user objects, or setup objects, and they will not be supported—at least not in the foreseeable future. So this picklist by now enables you to do less errors because you can't mistype an object name or so on. But it limits you for certain objects, and that's one of the issues we need to solve now. And We will be solving it. It's not a big deal. You will be able to use my triggers with any objects as long as you know the API name. But
[20:51] that's what I mean by invest. Okay, you committed to the framework. You made three great project with it. Now it's the fourth project that requires a user trigger for the first time. You hit a block because. There's a lack in feature. Luckily for us, all the trigger frameworks I know are open source or can be found on GitHub, and you can do a pull request or fix the issues for you. So it's always about the invest and frameworks.
[21:20] Depending on which, I mean, there are frameworks that consist of Jesus Christ six different types of Apex classes together in order to get a trigger framework handling, and we don't have that. We have one class and one test class, and you need three rows to implement the framework. That's it. No, no, no, Biggie. Because what I, from my experience, feel is that. Salesforce developers are on very very different levels. So some of some of us have seen enterprise implementations. Do know a lot of separation of concerns. They know what a service layer is. They know what the service layer and the other two are. Oh Jesus! Thank you. Yes, the selector layers. And for example, I myself never was involved in a project where the selector layer actually was needed. Oh really? I always have the service layer, and that can be enough. I don't necessarily need another a query layer in order to because it's too much overhead. The code runs fine. It runs in a decent time. It is future proof because it's bulkified. That's it. So I'm not hitting the requirement to go full-blown financial force-like separations of concerns, right? But still, it's another important thing is, and you mentioned it yourself, for such frameworks is separation of concerns in order to decouple
[22:50] stuff, get more insight into them, and in order to get standards, so not to think about, or not to open yourself up for for errors or issues and things that the framework could handle. So, frameworks are also a good choice if you feel you have the need to reduce boilerplate code. Because if you look at your five to six triggers, you see they're very very similar. First I do this, then I do that, then maybe I have a set of IDs that tells me if I am re-entering or if recurrency is happening, and so on and so on. And you will need to write and build that every time you create a new trigger or new trigger functionality. And in trigger frameworks, usually you have the helper methods there and. Sometimes even and that's what I enjoy most about reading on trigger different trigger pattern frameworks is to get an idea what kind of sugar or additional features the developers put in there, like an easy method to identify whether I have seen this ID in my trigger execution already or not, or easy methods to identify if a field has really really changed. And so on. And by really, really changed, I mean the issue with trigger. Old not being updated to an intermittent. Update happening within the transaction itself. Yes. Yes. Okay. Um. Okay. We talked a lot about the trigger framework.
[24:20] How do you select one? Do we really need one? And what is your this my trigger framework? The name was a bit confusing every now and then, but. Does it also accommodate to the new features in the Lightning platform? You mentioned the platform events, and we have the custom metadata. That we have the second generation packaging coming. The dependence injection. That's the beauty. Um, because uh, at the end of the day, as explained, platform events need to be dealt with triggers in code. You will be able to use my triggers with the triggers handling platform events just like any other trigger. Okay. Alright, so I know it's a little confusing. I need to say sorry, folks. You who are listening, I'm speaking about triggers in in different meanings, and now I'm speaking about triggers in the form of code. Meaning there's an Apex dot trigger file somewhere, and that's that's what I'm talking about. And so you can platform handle platform events. As for unlock packages, already explained. Yes, I think future proof because this trigger framework and it's the only one I believe handles namespaces. So it doesn't care if you trigger if you trigger classes live in package A, B, C or D. If they implement the my trigger framework, you will be able to configure everything in your Salesforce setup.
[25:50] Hmm, that's interesting. I think I I just need to dig into a bit the features and the code to see how these things are implemented. It's it's a vision and it's an invitation. Um, I'm repeating myself here. If every ISV today would implement my trigger and roll it out, tomorrow you have each customer would have a hundred percent control over the trigger. Full stop. But that's the ISV wants customer. That's a different question. That's a different question. There are two sides to those. Like. Don't touch my stuff, right? Yeah, I produce software. Don't touch my stuff. That's not the side I am on. I'm on the side of Salesforce is about customization. If I produce a product that cannot be customized using the standard features of the platform, I failed as an ISV. I simply failed. I'm I'm not giving people the options and the opportunities they have with any object or any any functionality on the platform. I just mock them down. So I instead of enabling them to be creative with my product, I'm forcing them to use the product in the way I foresee. And I'm I'm absolutely pro customization, which has a lots of issues, of course, for us ISVs. No worries. A life where they couldn't customize would be easier for us, a lot easier. But they can customize, and in my eyes, customers, subscribers should customize. And a good AppExchange solution
[27:20] will always enable you to customize in a certain way, at least. And if you can't, yeah, well, you can't. I see, I see. All right, thanks a lot, Sandor. I really enjoyed the things you you share with me, like the new features, the my trigger framework, and why do we use the trigger framework? And I certainly see your passion about the Salesforce technology. Thank you so much. That's that's really great. I mean, if there's if there's one message, it's it's we are witnessing several paradigm shifts. And platform events were the single most important feature in the recent years that completely changed my way about thinking of architecting or implementing Salesforce solutions. And I think we will go much more in the asynchronous way. We will get be getting rid of certain limits that us old developers know very well about, and I think those will get less and less. We'll see less and less distinction on the user interface side between synchronous or asynchronous events or things happening. And I think we should start. To to think about this paradigm shift. Obviously, we're all in in working orgs, and just a few days ago, platform events
[28:51] weren't there. So should we throw everything away? No, you shouldn't. But the next time you build something, or next time you have a new customer and a new Salesforce implementation, go challenge your assumption about how you can build business processes nowadays on the Salesforce platform because Lightning Platform gives you so many more. Possibilities, even conceptually, as I said, platform events conceptually are a completely new thing, right? And all the books that have been written, all the wisdom there is, is wisdom built on a world without platform events. And it will take us a few years to write new books in or and to gain the wisdom and experience with platform events. Thanks, Sandor. Thanks for all the great, useful information sharing with me. So I think it's a great moment for us to close the session. I don't know, do you still have something else to to mention? I'm happy if you are happy, Anna. I'm totally happy. Thanks so much for sharing this.
[30:01] If you enjoyed listening to this session and want to have a really easy way to support this podcast, Why don't you give us a quick rating or even a review on whatever channel you are listening to this show? If you are using iTunes, just go to SalesforceWay.com/itunes. It should open up the iTunes page for you. I read pretty much all the reviews you leave over there, and it really helps other people discover this show. So your support is very much appreciated, and I'm super grateful you have spent your invaluable time with me here. And I'd really love to hear how you think about this podcast. At last, I hope you are doing well, taking care, and see you next time.
