Amnon Kruvi joins to talk about the invocable method.
Amnon is an entrepreneur, Salesforce architect and developer, Salesforce MVP, and 14 x Certified.
Main Points
- We start our conversation with what is invocable method in Apex, and how to define it
- Then we chat about what is the benefit of using it and in what circumstances it fit better the business needs comparing to Apex trigger
- Finally, we go through what are the restrictions
Links
- Amnon’s twitter handle
- Article – Why Invocable Methods Could Spell the End for Apex Triggers
- Video – Invocable Methods: The Musical
Video Teaser – Musical Invocable Method
My Hands-on Video on Invocable Method
My Thoughts on This Topic
I have heard about the invocable method is before and vaguely known how it works. But I have never put in-depth thought on it. What is it really for? In what situation can it replace the trigger? Why can it bring the solution flexibility to the next level?
As a Salesforce developer, one of the essential skills is to know when to code and when not. This comes from years of hands-on experience and knowing what point-and-click can do.
In the previous episode, Andy Fawcett introduced the concept of Separation of Concerns. From that, I can draw a close analogy by using the invocable to fulfill the business requirements.
To summarize, the admins’ task is to define the condition and context to execute a process. The developer’s task is to put the complex data calculation action into an invocable.
Btw, I also recommend you to check the remarkable musical video Amnon did on the very same topic. It demonstrates the engaging power of the combination of knowledge and entertainment!
Question of Today
Have you ever used the invocable method in a real project? If so, what was your experience?
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:18] This is Salesforce Way podcast. In this episode, a guest is invited to talk on one specific subject. Our goal is to help our listeners to not only become better Salesforce developers, but more in general, better software engineers. So, hope you enjoy our content.
[00:41] Hey, everybody! This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I'm sitting with Amnon Kruvi from London, and today we're going to talk about a very interesting topic. It's the invocable method. Hello, Amnon. Hello, Shi. Hey, how are you doing today? I'm great. It's early in the morning, and I have the house to myself, so I'm quite happy. Yeah, I'm very thrilled actually today to talk you about this invokeable method because I see LinkedIn. You have a thread there. It's named Why Invokeable Method Could Spell the End of Apex Triggers. So I had to look at the content. I see many people were engaged in the comments. They ask, "Okay, what is this invokable method? What's the difference actually?" Since your title mentioned the Apex triggers, because for developers we all are quite familiar with the triggers, but this invokable methods it tends to be like a little bit different angle. So that's the reason I try to bring you into this show and educate me and our listeners as well. Well, that's an excellent question. The idea behind invocable methods is that you can create Apex code that runs using declarative tools like Process Builder and Flow. And when you give when you create tools like that, you can
[02:11] make Apex code run. Within the context of, for example, a process. Unlike a trigger, this means system administrators or declarative app builders also have some measure of control over when that code runs. Whereas when you design regular triggers, any change that you need to make has to be made by a developer. So I understand what you're trying to do is you separate the two concerns. You let the admins who are very good at the declarative tools to define the conditions when the invocable method should be triggered, should be running, and then you let the invocable method actually to do the job by itself. Absolutely. So you write a method that receives certain parameters, and that makes the method reusable. So an admin can use it in more than one place, and you give them that type of power. To control their own org with tools that would not normally be available on Salesforce, for example, things that are specific to an app that you're developing, or things that are specific to their org, any sort of business logic that you've made for them. Hmm. Because I also hear quite often that admins kind of complain that whenever we create a Apex trigger, only the developers has the power, has the access
[03:41] to modify. But on the other hand, the business requirement changes also quite often. So when there is only a minor change. To the business logic, then you need to go through the whole a release process. You have to ask the developer to change the code and test in the sandbox, in the QA, and then the final release. Maybe that has been multiple weeks has passed just for one minor change. It seems to me this invokeable method can somehow remedy a bit of that situation. Am I right? That is exactly what it's all about. When an administrator comes to a developer and asks for a change, if it's once a year, then maybe it's fine. But once you've once the project grows. The developers themselves actually start getting rather tired with all the change requests that come in, because you might have one change request about one topic and a completely different one about another, and eventually it becomes a burden. By giving more power to the declarative administrators, not only do we reduce some of that burden from us, but the admin becomes much happier because they can do things without having to ask someone else. That's a really powerful concept. So. Do I understand correctly that the you mentioned the process? That means the process builder and the flow as well. And in Salesforce,
[05:12] these two declarative tools admins can use them, and then that can somehow invoke the invokable methods that the Salesforce developers defined in the code. Do I kind of in the high level? Do I understand it correctly? That's right. When a developer creates an invocable method, and all it is is just a regular static method in a class that receives parameters and has a particular output, once you've created that class and that method, a developer can use it like a regular action in Process Builder or a flow. It's It's all drag and drop. You can use all the same utilities that you can in regular flow actions. You can pass inputs from your variables. You can put outputs into other variables. So, as far as the administrator or the app builder is concerned, it's completely transparent.
[06:13] When was this invokable method actually released? That's a very good question. I don't think I have a release version for it, but I've been using it more heavily for the last couple of years. It's possible that it that it existed before, and I just didn't know much about it then. I came from a mindset of always writing code. That's what developers like doing. Me too. Developers love writing code, and when the idea of of allowing declarative builders to write the application for you is something that developers are, I don't, I don't want to say afraid of, but certainly not happy to to do. I guess the right word is hesitant.
[07:00] Hmm. Yeah, that's that's a very important thing for Salesforce developers. We always need to keep in mind is when to use the code, right? So since now have the invocable method, we do need to think about in what situation it's better to use the invocable, which you just mentioned a little bit, and also in what situation it's better to use like only coding. Before we go into like what's the limits of the invocable method, could we still talk a little bit more about how to define the invocable method as a developer? So you mentioned that it's the static method, right? So I also understand that we have this annotation called the invocable method, exactly, right? And then we have a label, and then we have a description. That's exactly it. You don't have to remember much when you want to create an invocable method. You just put the annotation at invocable method just on top of your static method declaration. There are a couple of things to keep in mind. An invocable method has to take a list of input, so it can only take one parameter in the method, and that parameter has to be a list. Bugification. Exactly. That's because if you have five processes or flows running at the same time, they can be bulkified, and that method might be called with five different parameters at the same time. The end result
[08:31] is that your code runs faster and more efficiently. But as far as writing that method, it just becomes something that you have to keep in mind. We must have a list, and we must have just one single list. And that brings up the question: How do we get more than one parameter into our method? Well, that list doesn't have to be of any primitive type. It doesn't have to be a list of strings or a list of IDs. It can be a list of a class. And that class can be defined with more than one variable. And if you annotate those variables with the annotation InvocableVariable, I know it. How would you even consider that? Then those variables would appear inside Process Builder and Flow. Ah, okay. So if the input is a little bit more complicated, let's say it has multiple input variables, recommended way or the official way is to create a class that embeds all these variables, and then for each one of them, you give it another annotation called a invocable variable. And by defining that, and then you give this list of this your defined class into the input of the invocable method, then all those annotated invocable variables
[10:01] in the class will be appearing in the process builder in the flow. That's very precise. Inside the annotation, you can also define which variables are required. You can set required equals true or false, and you can also give them a human-readable label. So admins can understand more from the business reason what it is, and also the description what this function actually does under the hood. That would be the ideal situation. Okay, I got it. So developers, again, we try to when we create the invokable method to give a bit easier life for the admins to give a more descriptive information. That's exactly it. We have to keep in mind that we are creating this tool for people who are not accustomed to things like camel case or using underscores instead of spaces. So anything that we can do to simplify the experience is only going to make things better for them.
[11:16] Hi, just a quick note here. Don't forget to check the links shared in the show notes, where you can find the guests' contact information and the important complementary materials for each episode. In addition, I'd be so happy if you could share with me what you think about this podcast. You can reach me out by email, Twitter, LinkedIn, or website contact form. Your comments would definitely help me improve and deliver better content. So now let's get back to the show, shall
[11:50] we?
[11:55] And yesterday, actually, I also had a little bit study about this invocable methods. So Salesforce actually has a really good documentation, like a one page documentation about the invocable method. I'm gonna also put that page link in our show notes. So for for our listeners who really want to see how the invocable is defined, what does it mean, all those variables, you can definitely go and check that page as well. Now, if we shifting from the invocable method definition, you already mentioned there is a limit. There is no silver bullet that can solve all our problems, and then we can just get rid of Apex triggers. That's not the ideal world. We do have limitations, right? Of course, every job has the right tool. You you don't screw screws with a hammer. And and invocable methods have their place. They can provide a lot better quality of life for the end user, but we can't use them everywhere. So some of the limitations for invocable methods are the the fact that process builder and flows can't run in every context that a trigger can. For example, a trigger can run before an insert, or after a delete. Or under delete, whereas processes
[13:26] don't have before or after. A process always runs after a change, and it always runs after an insertion or after an update of a record, which comes out to a quarter of the context that you have for trigger. This is a very very important point. So I think for us, it's like we just need to know it exists, right? We need to know, and we we need to understand that an invocable method can be used to replace a trigger that would normally run after an insert or after an update, but it can't replace a trigger that runs before an insert or before an update. Hmm. Clear. That's a good conclusion. Do we also have some other limits, like the performance issue, or let's say if we have millions of the records coming down into the pipeline, do we have those limitations? So I've done some performance testing late last year, and I've found that on average, the performance difference is approximately twenty percent, which is not terrible considering the benefits that you gain as a developer. But, and this is an unofficial thing. So, for all we know, this is something that could be fixed in the future. But if you run an invocable method. On more than two hundred records in any single transaction, there is some sort of issue that
[14:57] damages performance rather significantly.
[15:02] So my recommendation would be to only use invocable methods if you estimate a transaction to be less than two hundred records. That's like a one chunk of batchable, right? Exactly. Interesting. Since you talked about what it is and what are the limitations, personally, I want to give it a try. But for me, it's always still a bit struggling here because it's very hard for me to cooperate with the admins. Because usually, what I do is the full implementation with code, and now I need to talk with the admin. I had to understand, okay, what are their requirement? Is there like a easy way for me to decide when I should use the invokeable? When should I use the trigger? Especially in the customer project. Well, personally, I think that developers and admins should work closer together. There is in in most companies that I've been to. There is a disconnect between the developers and the administrator for the end user. Whether you're consulting or whether you are developing an application, most of the time there is someone in the middle who who does that communication between you and the administrator. But it doesn't have to be that way. No one is blocking you from talking to them, understanding what their capabilities
[16:32] are, and if if they're a good declarative builder. Then ask them what utilities would be useful for them. Thanks for this. I think this is definitely a lesson for me to learn. You know. Always to communicate actively with the admins in the company. Because I'm doing the Salesforce consulting, so most of time we are kind of dragged into a new project. We we have the time restrictions, and maybe the admins are not part of the project most of time. We only have the project team who are building this new solution. So maybe when the project is almost completed, then that means we're we're jumping the board and say, okay, now we present you. This is the solution we give you. And you can see how that could cause problems further on down the line, because if the system administrators are not involved in the design part of that project, they can't express what they need from the project. Then chances are that they're going to be disappointed with what they are given. Hmm. Exactly. You know, sometimes I feel that the architect design the solution without asking developers. Now, for the developers, maybe we're doing a similar thing. We didn't even noticed about you know without consulting our lovely admins. So I think definitely we need more collaborations. And this invokable method, I really love it.
[18:03] It separates the concern. It made made the solution more flexible. We use much less code, and we can complete more situations and more problems. From my experience, I I used to work with in consulting for a couple of years on Salesforce, and it there was a very clear distinction between those clients whose projects I was able to complete using invocable methods, and the ones with whom I couldn't. In in the sense that, the ones who had invocable methods could take control of the project and they could make changes. Sometimes without even telling me that they need anything, I would just log on the next week and see that they took things to a whole other level. Which was great because that meant that I didn't have to be involved and I didn't need to make those changes, so I could actually have a Saturday off. And in consulting, that that can be quite rare. Yeah, indeed, kind of delegate that part of task to the professionals who are good at define and precondition the data input, and then use your invocable method to to do the job. Excellent. I love that. All right. I think that's a really good quick lesson from you about this invoke method. So I think we almost can close the session.
[19:34] Before we let you go, do you have some other comments or anything you want to bring up? I. Don't have any other comments, but I just wanted to say that your show is great. I'm really happy that that you are taking the time to to make it, and it's it's people like you who help support the the community by doing things that are a bit untraditional. Oh, oh, that's really nice of you saying so. Thanks, Amnon. And I've really enjoyed talking to you. Yeah, me too. Excellence. Thank you very much. Hey, this is the end of the show. If you enjoyed the content, please connect with me and let me know your thoughts. All my contact information is available on the website at SalesforceWay.com. Thanks for listening. See you next time.
