My organization is starting to feel some pain around using Process Builder + Flow (error handling mostly, but also inherent Flow inefficiencies and the inability to run Flow in system context).

Thus, we're starting to opt more for Process Builder + Invocable Apex. I've searched around for best practices, but haven't found much. I would ideally not want to have a million classes, each with one specific invocable method performing one specific function. However, given the "one invocable method per class" limitation, I'm struggling to come up with an efficient way to organize these classes.

As it is, I've got it structured as:

  • [Object][function].cls - class which performs the specific logic
  • [Object][function]_Invocable.cls - only contains the @Invocable method and the inner class with @Invocable variables. The method calls the specific class (above)

The only idea I've come up with is to add a string variable to specify which actions to perform and do a bunch of IFs. Of course, that requires foreknowledge on the declarative side of the valid strings...which I suppose isn't the end of the world.

Anyway, curious if anyone has thought of a more elegant way to handle this.

  • not directly on topic but if @invocable throws any exception, the results aren't pretty in Process Builder. On topic, the PB admin shouldn't have to know about how to marshal arguments to your dispatcher. I like separate classes / methods that clearly identify what they do so it is easy for the PB admin to know what to select
    – cropredy
    Dec 6, 2017 at 1:51
  • @cropredy - So to confirm, even if they're caught, exceptions will still throw the "Failed to Trigger a Flow" garbage? I agree that it's not ideal to have the PB admin have to know how to marshal arguments, but to me, a huge proliferation of single-purpose invocable classes seemed worse (that could just be me though).
    – Mike
    Dec 6, 2017 at 14:57
  • uncaught exceptions are the issue, or if the @invocable throws an exception expecting PB to catch it and do something friendly with it. As to the volume of classes - depends on your POV - as Apex guy, you should be making life easier for your "clients" - in this case the PB Admin. As you know, PB is damned hard enough to debug
    – cropredy
    Dec 6, 2017 at 16:51
  • @cropredy Perhaps it's shortsighted of me, but given that I'm only in a team of two and we're both doing admin & developer tasks (both declarative & programmatic), I'm not terribly concerned with a tiny bit of extra effort on the PB admin side (e.g. opening my painstakingly created documentation). I am trying to catch exceptions and write debug statements throughout, but as far as the uncaught exception pain...at least it's not worse that dealing with Flow?
    – Mike
    Dec 7, 2017 at 3:18
  • food for thought: I borrowed ideas from this blog so all my flows would send out detailed diagnostics to the sysad
    – cropredy
    Dec 7, 2017 at 5:04


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.