Mitch Spano is an Application Engineer over at Google. After running into orgs with complex problems juggling automated processes and triggers, Mitch created the Trigger Actions Framework project and that is what we are discussing today. We also get into some best practices for Apex, which Mitch is very experienced in learning and using.
In the episode, Mitch shares a fun story about how he got started writing computer programs just so he could make his math tests easier. From there he was forever hooked on the coding ecosystem. We’ll go into the use cases for the Trigger Actions Framework, how both developers and admins can adopt it, and what makes it tick. Tune in to learn more.
Show Highlights:
- Things that developers who are new to Salesforce should know.
- The difference between an “object” in Salesforce and computer programming.
- The first thing Mitch does when starting a Salesforce project.
- The issues with using opportunity trigger handlers as solutions for automation and order of execution.
- What the Trigger Actions Framework is.
- The metadata structure of this framework.
- How developers can replace what they’re doing with this new framework.
- Advanced features the framework for controlling the flow of actions
- Options for testing with this framework.
- When you would use the feature within the framework that allows you to limit any further actions on an object.
Links:
- Mitch on Twitter: https://twitter.com/MitchSpano
- Mitch on LinkedIn: https://www.linkedin.com/in/mitchspano/
- Mitch on Github: https://github.com/mitchspano
- Trigger Actions Framework: https://github.com/mitchspano/apex-trigger-actions-framework
Episode Transcript
Mitch Spano:
If you knew me at a young age, you might imagine that I would be in this profession.
Josh Birk:
That is Mitch Spano, an application engineer over at Google. I’m Josh Birk, your host for the Salesforce Developer Podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Mitch about his trigger actions framework product, as well as some best practices about learning and using Apex. But we’ll start with his early years in an interesting little story about an opportunity he had for coding.
Mitch Spano:
Yeah. So, actually, in seventh and eighth grade, I had these two wonderful math teachers, Mr. Hovan and Mr. Ron, and both of them, they always kind of ran their classes similarly, and they both had this rule where you could use your TI-83 graphing calculator on a test. And if you wrote a program on that computer, on that calculator, excuse me, and you used it on the exam you’d be able to use that during the exam. So, as long as you wrote the code and you didn’t just use the little link cable to get the code from someone else, you could use your code on an exam. And I, as a kid, I thought, oh man, this is awesome. I’m going to cheat on this exam it’s going to be so easy. The act of creating the program was the studying for the exam. And I could have done it without the program, but that was my first real entrance into writing computer programs, all for making an exam easier. And now here we are many years later.
Josh Birk:
Gotcha. Nice, nice. And people, they approach the Salesforce platform in different ways. We’ve got people who kind of… We’ve got admins who sort of ended up dabbling in coding. We’ve got people who come from other skillsets, like business or music, and they kind of end up picking tech on the side. But you come from a very, fairly advanced computer science background. How did you start approaching Salesforce with that mindset?
Mitch Spano:
So, when I first got into Salesforce, I was learning alongside some of the more senior experienced consultants that we had that were helping us implement this project. At the same time, I’m going through the formal Salesforce training, where before Trailhead was a thing they’d get you all in this room and put everybody together and they’d have an instructor and it would go through. And I started off with the admin training as my formal training.
Josh Birk:
Oh, wow. Okay.
Mitch Spano:
So, right out of undergrad, yes, I had a lot of computer science expertise. But I started out my Salesforce career learning the fundamentals of what it takes to be a good Salesforce admin. And as I started that, I immediately saw the benefits of utilizing this low code platform to define how you want an application to behave.
Josh Birk:
Got it. Got it. And that’s something I’ve heard pretty frequently, right? Good developers often have good admin. At least, they have the tools at their fingertips. But let’s flip that around a little bit. When there’s developers on the platform who are maybe not coming from your experience or don’t have the senior developers there to show them some of the right things to do. Are there big things that you wish that early developers really should know?
Mitch Spano:
So, we’re talking about experienced developers who might be in a different skillset coming to the platform for the first time?
Josh Birk:
Yeah.
Mitch Spano:
Yeah. So, the first thing that I wish that somebody else would have explained to me is that Salesforce handles a lot of these things for you and they give you a lot of tools where you can choose to build whatever you truly want, but there’s a reason why they keep you on the well-lit path in terms of staying with declarative point and click solutions that are part of the core platform instead of utilizing it as this blank canvas application development platform.
Josh Birk:
Right.
Mitch Spano:
Yeah. So, some of those things that I wish somebody would have explained, or I wish I was a little bit more experienced in earlier in my career would have been things like authentication.
Josh Birk:
Mm-hmm (affirmative).
Mitch Spano:
If you are brand new to Salesforce, but you’re an experienced developer, you might be used to interacting with credentials stored in a key store somewhere. You might not necessarily understand what the named credentials part of Salesforce is for. So, you might accidentally rebuild something which already exists on the platform.
Josh Birk:
Right. And going back to that, it’s nice to have like a good breadth of those declarative skills at your disposable. Now, flipping that around a little bit. What about the person who is maybe coming from a less technical background, a less experienced background, and they just sort of start picking up, especially Apex, from the examples they see on Trailhead and the examples they see on documentation. What are some things from a CS background that you wish you could inject into their brains?
Mitch Spano:
Yeah, so the number one thing that I think is really challenging to wrap your head around is probably just a Salesforce vocabulary thing. Salesforce calls all of their database entities objects, and in computer science, an object is a little bit different. So, an object is something that you have allocated memory for. So, for example, if you open up solitaire on an old Microsoft computer, there’s an object for each one of the cards that’s in the deck.
Josh Birk:
Yeah.
Mitch Spano:
There’s an object representing the state of the deck. There’s an object representing the state of the game. And none of those are actually saved to a Salesforce record. So, the explanation between what an object means in terms of computer programming versus what an object means when you first learn Salesforce. Because I think a bit of a challenging vocabulary leap for a lot of folks on the platform.
Josh Birk:
Well, and that’s interesting because for me… And I’m the guy who went from Pearl and CGI scripts and very procedural style programming to learning how object-oriented worked by modding on the Unreal Engine and coming up with cool thermonuclear grenades and stuff like that. But if I didn’t have that background… And that’s a really good way because it’s like objects in Salesforce have a very, it’s not even vernacular, they’re custom objects, capital C, capital O. They’re standard objects. They’re right there front and center when you think about developing it. But one of the things we don’t really, I feel like inject in people’s object-oriented concepts and polymorphism and stuff like that. And it’s like, how can developers get from talking about things like the gang of four concepts if we haven’t even put that into their brain first?
Mitch Spano:
Yes. Yes. I think that the fundamentals of object-oriented programming that is abstraction, encapsulation, polymorphism, and inheritance are the things that we should immediately start talking about as soon as folks understand those elementary ideas of what an object is.
Josh Birk:
Mm-hmm (affirmative).
Mitch Spano:
So, the object vocabulary still is a hurdle that we need to tackle.
Josh Birk:
Right.
Mitch Spano:
But once you understand what objects are in the sense of your program that you’re trying to do, be it maybe some trigger logic, maybe you want to control a lightning web component or a visual force page. You need objects to define how is this actually going to work. And once you understand how those objects are constructed, how you use them to define application functionality, that’s immediately the point where we as a Salesforce community, need to interject and start focusing on some of the core object-oriented principles and teach that to the engineers who might be newer to the platform.
Josh Birk:
Yep. Yep. Totally agreed. And I kind of named drop there a little bit, but level-set for being the other people. What is the gang of four and what kind of concepts are they talking about there?
Mitch Spano:
Yeah. So, the gang of four is an architectural pattern book that was written back in the nineties. I’d have to look up the exact publishing year, but it’s these patterns in which you can specify a group of objects that will interact with each other to facilitate a computer program. And they have very, very low-cost long-term cost of ownership. So, it’s very easy to extend and utilize these patterns. And they have very, very many different uses across all different sorts of technologies beyond just Salesforce.
Josh Birk:
And to highlight, you don’t have to get a master’s degree in computer science to handle this kind of stuff. Not saying you shouldn’t get a master’s degree in computer science, should you want to do that. I think actually when I was researching this, that book is 20 years old and it’s still a best-seller, right? People are still recommending it for just what you just said, that these are concepts that are not particular to any one style or language of development, but any of them. Speaking of not having a computer science degree, humorously, I almost bailed on programming because back in the day I was just entering in code from random computer magazines into my Commodore 64 and I would just get so frustrated whenever there was a syntax error and I couldn’t just play the maze game that I was trying to get to.
Mitch Spano:
Yeah. Yeah. So, when I was fresh in undergrad, my first class that I ever took, 7:45 AM.
Josh Birk:
Oh.
Mitch Spano:
I don’t know why. It’s just a novice freshmen mistake to enroll in a class at that time, but it was also computer science 120. And that was like intro to computer science for computer science majors. And I took that class. I found it interesting, but I found it so tedious that every single time something didn’t work, I just needed to bash my head against the computer and try 600 different ways to figure out how to make a little… One of the capstone project for that semester was we made the little snake game that you could play on your Nokia phone.
Josh Birk:
Mm-hmm (affirmative).
Mitch Spano:
That was our introduction to linear data structures. That was our capstone project for that.
Josh Birk:
That’s awesome.
Mitch Spano:
But I remember getting so frustrated during the first few months of trying to learn computer programming that I even switched my major.
Josh Birk:
Oh, wow.
Mitch Spano:
I was originally a computer science major and I said, “No, I don’t want to do that.” Then switched it to math because I figured I’d need to know math anyway, at some point, no matter what I wanted to do. But then I ended up taking a bunch of math slash computer science courses and veering back onto that path. But I almost threw in the towel right away.
Josh Birk:
Nice. But they just kept pulling you back in.
Mitch Spano:
I know. I know. I know. If you enjoy it, you’ll be attracted to it.
Josh Birk:
Right.
Mitch Spano:
And for me, I view these as puzzles and I really get a lot of satisfaction out of making something work and work slickly and elegantly and work the right way. So, yeah. I think it was kind of in my destiny. I don’t think I could have stayed away for to long.
Josh Birk:
Nice. Well, let’s talk a little bit more about that. Because we’re talking today about a project of yours that kept coming up in my Twitter feed, which for the curious is a really good way to get on the podcast is if you do a really cool project and then a bunch of people keep talking about it on my Twitter feed. But before we talk about the project itself, let’s talk about what led up to it. In your seven years of experience with Salesforce, what is shall we say the most common state in Salesforce specifically getting into different Salesforce orgs, what’s the most common state you’ve seen when it comes to different automation tools from flow to triggers ending up in the org?
Mitch Spano:
Yeah. So, small minor correction, eight years of experience now.
Josh Birk:
There we go! Okay.
Mitch Spano:
I’m getting old, man.
Josh Birk:
I hear you. I hear ya.
Mitch Spano:
So, I do think that one of the first things whenever I have historically joined a Salesforce project, one of the first things that I’ll do is I’ll take a look at some of the most commonly used core objects. So, opportunity in a sales cloud implementation or case in a service implementation. And I’ll just take a look and see what does the trigger look like on that S object? What are the process builders like on that S object?
Josh Birk:
Uh-huh (affirmative).
Mitch Spano:
Are there any flows and are there any workflows? Because if I know that if I can find things in all of those different four categories, it’s going to be tough for me to figure out how the system is going to behave.
Josh Birk:
Right. Right. Exactly. And I think this kind of dovetails back to what we were talking about before because when we see Apex and documentation, we see Apex in Trailhead. We see it as this set of similar classes that are off doing their own thing. And then when you add in Flow and you add in process builder and it all just sort of keeps adding on. But as anyone who’s spent a lot of time, late at night, trying to prove the order of an execution knows a lot of people resolve that kind of problem that you’re describing with sophisticated structures like handlers. When did you get to an inflection point where that wasn’t really good enough to solve what you’re describing?
Mitch Spano:
Yeah. So, a lot of folks, when I first started my Salesforce career, there was a lot less structure and a lot less available documentation about what was the appropriate trigger handler framework. So, a lot of times you would see folks who would kind of just create this class that had these static methods called opportunity trigger handler, and it would just pass in the things. That was nice because it allowed you to separate your logic from the calling trigger, but it left some room for ambiguity in terms of the method signatures. With those methods being static, it means that they were really unable to reuse a lot of code which might be defined elsewhere.
Josh Birk:
Hmm. Okay. Okay. And it also feels like that solution was almost more about trying to work around the weird vagaries of, because the trigger class is a specialized thing, and it’s difficult to work with it with unit tests and putting it into productions and things like that. And it doesn’t really resolve any greater organizational challenges. Right?
Mitch Spano:
Yeah. So, it really does do a great job of separating the logic from the calling trigger and allowing you to control the order of execution within that trigger. And I think that was probably the main goals that were intended by the use of the first or second generation of trigger handlers on the Salesforce platform. Make sure that I can control the order of execution. Okay. Check.
Josh Birk:
Right.
Mitch Spano:
Later on in my career though, I started getting involved in orgs that were bigger. Orgs that had multiple different business units. And so when there’s multiple different business units and they’re all trying to sell stuff using the opportunity S object, most orgs will probably have a record type. Let’s just say retail versus wholesale.
Josh Birk:
Mm-hmm (affirmative). Mm-hmm (affirmative).
Mitch Spano:
And then they’ll probably try to partition their trigger logic. It’s like, okay, this is the retail opportunity trigger handler and this is the wholesale opportunity trigger handler.
Josh Birk:
Got it.
Mitch Spano:
Yeah. So, that’s where I started to realize there might be a better way for us to partition our trigger logic and control the order of execution that doesn’t create this weird ambiguity of like, what is an actual trigger handler? Where does the logic go? Are we just making two trigger handlers here?
Josh Birk:
Right. Right. So, let’s use that as a jumping-off point then. And I think you’re possibly going to repeat a little bit about what you just said, but give me the elevator pitch for the trigger actions framework.
Mitch Spano:
So, the trigger actions framework allows developers and administrators to partition their automation that would historically be held all in one trigger handler into individual small classes with a sole responsibility for each class.
Josh Birk:
Okay.
Mitch Spano:
It also allows for developers and administrators to work together by orchestrating the controlled order of execution of Apex and Flow together.
Josh Birk:
Which is an interesting design goal. One of the things that you say with it was that you are not trying to, and I’m putting my words, I’m paraphrasing for you, but it’s like you’re trying to not dismiss either one of them based on their skillsets that you actually want them working together and be in control of their own destiny.
Mitch Spano:
Correct. Correct. When you get into those big orgs, you oftentimes have a lot of automation, which you require complete control over the order of execution. So, you’ve written all of that logic into your trigger handler. Then you might need to split it up. Then you have a retail trigger handler and a wholesale trigger handler.
Josh Birk:
Correct.
Mitch Spano:
So, then it gets a little dicey. The problem is though, is that when you do that, you leave a whole bunch of really strong declarative admin skillsets on the sidelines. Your admins then are only there for basically creating reports and screen flows and fields.
Josh Birk:
Right.
Mitch Spano:
So, all of the core automation that an admin is used to providing on their previous projects, all that valuable experience that they’re bringing to the project is sitting on the bench and you don’t want to have that.
Josh Birk:
Yeah. Well, and I’ll go back to something that we stated a lot when we started doing the road trips for talking about process builder, and then later Flow. It’s like previously developers were responsible for building a lot of really boring triggers that looked an awful lot similar. They’re very similar to each other, that then had to have a lot of unit testing. And then they were just sort of sitting there waiting to break production someday. And it’s like if the admin can get that done using their skillset, that frees up the developer too. And I think we keep using this phrase, go do the more interesting stuff.
Mitch Spano:
Right. Right. So, if you can find a way for your admins to be able to introduce new record based automation in a way that doesn’t interfere with the developer’s ability to have control over the order of execution, then I think that that’s where you can really unlock some new levels for your team and be able to develop and deliver a lot more rapidly on the Salesforce platform.
Josh Birk:
Yeah. Yeah. I could see that. So, let’s take a look at this from a developer’s point of view. I have an org. I’ve been pretty good about my code. I have a decent handler structure in place, no business logic touches my actual trigger classes, but I want to take it a step forward and start implementing what you’ve done. What does that look like from a developer point of view to replace what I’m doing with your framework?
Mitch Spano:
Sure. So, I guess I’m going to take a step back in order to answer that question. I’m going to give a little bit more of a view about what the engineering or the developer life cycle looks like when working in the trigger actions framework.
Josh Birk:
Got it. Okay.
Mitch Spano:
So, with the trigger actions framework, your triggers are just a one-liner. They call a thing called the metadata trigger handler. So, you set up this one-liner trigger handler and you have these rows of these custom metadata that would correspond to basically each S object that this is enabled on. So, you’d have a row for case you’d have a row for opportunity. Then as you need to introduce automation on the case S object, you would write an individual class that implements the right interface, and then you’d create custom metadata to plug that class in and say, “Ah, this class is the first thing that happens before insert on the case S object.”
Josh Birk:
Okay.
Mitch Spano:
So, then if you had some more logic that you needed to have, execute before insert, you would just write another individual class and then use another row of metadata to slide it in, in the right order. So, they’d say, “Ah, the other one is the first one. This new one is the second thing that happens before insert on the case S object.”
Josh Birk:
So, tell me a little bit more about the metadata structured itself there. It sounds like that’s extremely vital to what you’re trying to get done here.
Mitch Spano:
Correct. Correct. So, there’s two pieces of metadata in the framework. One of them is called the S object trigger setting. That just enables the trigger actions framework on a given S object type. So, you would enter in, like I said, case, opportunity, account, whatever you want. Then there’s another piece of another type of metadata called the trigger action. The trigger action has multiple relationships to the S object trigger setting. And those relationships are called before update, after update, before insert, after insert. So, the idea here is this, you create the parent S object trigger setting metadata record, and then you’ll create an individual trigger action record and specify the context that that’s supposed to happen on for the given S object and the order in that context in which it’s supposed to happen.
Josh Birk:
Got it.
Mitch Spano:
So, you can say before insert, on case, or here’s the first trigger action. Here’s the second trigger action. Here’s the third trigger action.
Josh Birk:
Got it. So, you’ve taken custom metadata, abstracted the concept of a handler one part even more, and made it a common meeting ground that both developers and admins can go in and start definding what objects are being treated on and what objects are being triggered on, what actions are going to occur after that.
Mitch Spano:
That’s Correct. That’s correct. So, if you take a look and you have everything set up with this framework, you’ll able to just click into the S object trigger setting itself for the corresponding S object and you’ll see in the metadata related list, all of the actions that occurred before insert.
Josh Birk:
Nice.
Mitch Spano:
So, you’ll say before insert, we prevent the opportunity from being inserted unless the stage name is prospecting.
Josh Birk:
Got it. Got it.
Mitch Spano:
And then before insert, we update the parent account if the region is Minnesota. Whatever your business logic is, you just control that and you see a row for each one of those actions you need to take.
Josh Birk:
Got it. All right. What I love about this, this is now the second interview I’ve done, which is proving why custom metadata is one of those unsung portions of the platform that if you haven’t started tinkering with it, you should start now.
Mitch Spano:
Yeah. Absolutely. A small plug here for Custom Metadata. If you have ever been in a Salesforce board where you used S objects to store configuration records that would facilitate some of your business processes, Custom Metadata is probably really going to be an applicable solution to refactor that logic. So, a prime example which comes to mind is let’s just say you had a custom approval process. You had an approval process, but you didn’t want to lock the record. You had these weird things where maybe you had specified. The business had some weird approval processes that they wanted to implement and it did not jive well with out-of-the-box Salesforce approvals.
Josh Birk:
Yeah.
Mitch Spano:
You might use Custom Metadata to store. For this type of record, these four levels of approval are applicable.
Josh Birk:
Nice. Nice. So, let’s flip this back to the declarative person, the declarative coder slash admin. What are some things they need to know? How is their work with Flow going to change if they’re implementing the trigger actions framework?
Mitch Spano:
Yeah. So, just like how the developer writes an individual class that just plugs into the framework using the metadata. Admins can write flows, which will plug in, in the exact same mechanism. So, let’s just say, for example, you had the case S object and you had a before insert, you modified some field and you set the case subject to, “Hello world.”
Josh Birk:
Right. Right.
Mitch Spano:
You could, as an admin also write a Flow using the trigger actions framework, which would be able to modify those field values before the record even gets inserted, and then you’d be able to say, let’s just say that the Flow sets the subject to, “Goodbye world.” You’d be able to specify, does the Flow happen before the trigger or does the Apex action happen after the Flow? So, you can control if you want, when the record actually hits the database, do you want the subject to say, “Hello world.” Or, “Goodbye World.”
Josh Birk:
Got it. Got it. Now, you’ve also got a couple of interesting fail-safes built into this like recursion protection and runaway queries. Back to back how do those things work in the framework?
Mitch Spano:
Yeah. So, as a Salesforce developer, recursion prevention is incredibly important on platform because if you have an update which induces and updates to the same record, you have to make sure that you’re not recursively updating that record until you cause a failure.
Josh Birk:
Right.
Mitch Spano:
Right. Right. So, the way that the recursion prevention is handled in the framework by basically holding an occurrence map of all of the IDs that you’ve processed. And you have two maps, one of them before update, and one of them after update.
Josh Birk:
Okay.
Mitch Spano:
So, as records go through the trigger itself, then they’ll increment the number of time that that ID has been seen.
Josh Birk:
Okay. Got it.
Mitch Spano:
So, you’ll be able to say, “If this is the first time I’ve seen this ID before update, then I’m going to take this action. But if I’ve seen it before, then I’m probably going to omit it from processing for this action.”
Josh Birk:
Right. I feel like it’s almost like a bouncer who’s reviewing driver’s licenses. The first time they see the license, no big deal. But if they see the same license, 100 times in a row, there’s something weird going on there.
Mitch Spano:
Right. Right. They’re going to turn you down no matter how cool the car you drive or who you came with. You’re not getting in.
Josh Birk:
Right. And they might ask you who’s been making your fake copies too.
Mitch Spano:
Right. Right. Right.
Josh Birk:
Now, talk to me about runaway queries. Does that work in a similar way?
Mitch Spano:
Yeah. So, runaway queries I found that there could be multiple actions that you want to take, which require queries to the same set of related records. So for example, if you’re on an opportunity S object, you might need to fetch attributes from the parent account. So, the parent accounts name, the parent accounts states, the parent accounts zip code, whatever it needs.
Mitch Spano:
And there could be multiple actions which require those attributes in order to implement their logic. So, included in the documentation for the trigger actions framework, we show an example where we avoid repeating those queries by using a pattern called the Singleton Pattern, which will guarantee that there’s only ever one instance of an object in memory at a given time.
Josh Birk:
Gotcha.
Mitch Spano:
Then we’ll perform those queries as the first thing that happens during the trigger context. So, before insert, for example, we execute all of our queries. We store them to the object that’s referenced at using the Singleton Pattern and then they’re available for any subsequent trigger action after that.
Josh Birk:
Got it. Nice. Nice. I like two things about that as well as the recursion protection. First of all, Singleton is another concept that unless you’ve dug into the nerdy sides of computer science, it’s not something typically called out, but it’s something that when you need one, there’s no other choice. You’re doing that, and you just sort of need to know that that structure can exist in programming.
Mitch Spano:
Correct. Correct. This is why I think it’s really important that we as a Salesforce community start bringing up these topics as an important part of a developer’s career progression early in the development life cycle to save folks from all of those opportunities where you could have implemented a pattern, but you didn’t because you had never been exposed to it. Or you might not have had a senior developer guiding you, or maybe even you might be a lone wolf.
Mitch Spano:
You’re a system admin who got promoted to developer. So, the odds of you coming into interacting with one of these patterns in the wild is pretty minimal-
Josh Birk:
It’s pretty minimal. Yeah.
Mitch Spano:
but there’s a large cost though if you don’t implement the patterns and it’s a hidden cost. It’s a hidden cost that we as Salesforce developers, consultants, admins, and architects are passing that cost onto the Salesforce customers who use the platform because it’s an opportunity for us to be needed in the future less. It’s an opportunity for the things that we build today to stand up to the test of time and be able to be used without being modified in the future.
Josh Birk:
Right. Nice. And the other thing I like about both of those concepts is that these are problems, recursion, and runaway queries. These are things that can run really smoothly in developer or sandbox, but then there’s that one custom field or that one weird record in production that blows everything up. And that, to me, dovetails back into testing, which is where we’re trying to catch those things before they occur in production. But your framework fundamentally changes testing. What impact does it have or maybe a better way to put it is, what options are you giving people for testing with the framework?
Mitch Spano:
Certainly. So, the way that we’ve historically on the Salesforce platform tested our trigger logic was by inserting, updating, deleting, or undeleting records.
Josh Birk:
Right.
Mitch Spano:
That’s the injection point, right? The DML operation needs to happen for the trigger to get called. And then our logic will flow through from that. Now, when we do that though, and anybody who’s been in an org that’s been around for a while will understand that DML operations get slower and slower as time goes on, and as more automation gets introduced into the org. So, it probably only takes maybe 400 milliseconds to insert a case in a scratch org, maybe even less. But in a production org, that’s been around for six years and it has had four different teams working in it with a mix of process builders and workflow rules and flows and trigger logic, it might take four seconds for every case that you insert.
Josh Birk:
Right. Right. Which doesn’t sound like a lot of time, but it is when you’re testing things.
Mitch Spano:
Well, it is when you’re testing things and if you think about the number of users that you have in the system as well too. So, the testing part is one thing that we as developers are intimately familiar with. But you think about the cumulative number of man-hours that your whole sales or service organization needs to spend waiting those four seconds for those cases to get inserted into the database. That adds up to a lot of productive time wasted.
Josh Birk:
Right. Right. Now, with the actions framework though, you can actually run a test without any DML. How is that working?
Mitch Spano:
Yeah. So, in the old trigger frameworks that everybody has been using, historically, you have to call the DML like we just said. In this new trigger framework, I wrote a small class called the Test Utility. And the Test Utility will allow you to generate a syntactically correct fake record ID for a given S object type.
Josh Birk:
Got it.
Mitch Spano:
So, you could say give me a fake case ID.
Josh Birk:
Got it. So, a completely abstracted data layer that doesn’t actually have to deal with any DML.
Mitch Spano:
You don’t need to insert the case in order to fetch that case ID. You just need to call that method and it’ll generate a syntactically correct one for you. So, you can assign that case ID then to a case that you have in memory and then pass that in as the element in the new list to your trigger action. And then you can basically mock out the injection point of your test to basically call your trigger action logic without ever having to insert the record whatsoever.
Josh Birk:
Nice. Nice. And then one other feature you have is the ability to bypass any further actions on an object. And while I get that as a verb, give me a good use case as to why somebody would want to do that.
Mitch Spano:
Yeah. So, there’s three actual different ways in which you can bypass automation on your S objects using the trigger actions framework. One of them is this global turn-it-off checkbox style of automation. On each one of the trigger actions or on the S object trigger setting, you can say, “Turn this off.” And there’s just a bypass execution checkbox. If you check that box, it’ll no longer be active. So, if you do that on an individual action, you’ll turn off the action. If you do it on say the case S object trigger setting, it’ll be essentially turning the case trigger off.
Josh Birk:
Nice.
Mitch Spano:
So, that’s nice if you have something which you just deployed and it’s breaking something and you need to turn it off right away. Boom! Done. Done. You don’t need to wait for a deployment. Super-helpful there. Or if you want to deploy something up to prod and have it lie dormant, and then activate it at a later date. Very helpful.
Josh Birk:
Nice. Okay. So more abstraction, more control over the flows, protection from things like recursion and query limits, bringing in developers and administrators, some DML-free testing. Is that a good summary or am I forgetting anything?
Mitch Spano:
I think that that’s a pretty good summary. I think that that’s a pretty good summary. There are also a couple of other things you can do. There’s also a nice permission-based bypass engine. So, this will be helpful for if you want to bypass actions for a specific profile or a specific user. So, let’s just say you had a data integration user or a data integration profile, and you didn’t want them to execute automation on the opportunity S object. They’re just supposed to dump records into the system and let them be. You can implement that user or profile-based bypass using the trigger actions framework.
Mitch Spano:
The final way is there’s an apex interface as well, an interface for you to bypass the trigger framework, where you can say trigger-based bypass and pass in an S object name. Now, I wouldn’t recommend this in normal production code, but it’s a super slick way for you to bypass things in those unit test scenarios where you actually do need to insert something.
Josh Birk:
Right. Or you just don’t want to beat around the other 1300 pieces of automation that might be working at the same time.
Mitch Spano:
Exactly. Exactly. If you’re trying to test opportunities and you’ve got a whole bunch of account automation. You might just want to bypass the automation on your account, insert the account and then use it for your testing of opportunities.
Josh Birk:
Just prove your code works and get everybody else off thon.
Mitch Spano:
Yeah. Yeah. But an important part to know is that these are really trying to take what have historically been integration tests on the Salesforce platform. And we’re trying to open up the ability for developers to write true pure unit tests.
Josh Birk:
Got it.
Mitch Spano:
When you’re only trying to test the scope of the public method that you just wrote. This doesn’t mean you’re absolved of responsibility for writing system integration tests though. You still should have a handful of tests that insert the records to the database and assert that everything’s working smoothly together.
Josh Birk:
Nice. Nice. And this is all open-source, right?
Mitch Spano:
This is all open-source. You can check it out on GitHub if you want to.
Josh Birk:
Which and people should, because again, just bringing this point home again, if you’ve never seen a Singleton in operation, having an open-source project that’s showing you how a Singleton works in operation is a great way to learn how Singletons work. And that’s our show. Now, we will link to Mitch’s project in the show notes so please go check that out if you would like to learn from it, use it or collaborate on it. Now, I did ask after Mitch’s favorite non-technical hobby and I will admit it’s one we have not heard before.
Mitch Spano:
I’m going to say eating ice cream. Honestly, it might sound silly, but folks who know me and have known me throughout my career and my life would probably say the same. I can not say no to sweets, man. I’ve got a sweet tooth and I cannot turn it down.
Josh Birk:
I want to thank Mitch for the great conversation and information. And as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can see the show notes, hear old episodes, and have links to your favorite podcast service. Thanks again, everybody. I’ll talk to you next week.