When a Trigger Meets a Process Flow Comin’ Through the Rye

This is not general reading, despite my attempted literary reference in the title. This is a solution to a specific problem that I encountered, and that I’ll document here in case someone needs it later, since I failed to find the solution when *I* googled it.

I had a process flow that was calling an Apex @InvocableMethod that used the getContent() method to attach a dynamic pdf to an email. The process flow was called when an Event Registration record changed status to Registered. Works great when you go in and manually make that update to the Event Registration. No problem! Code is sound!

But, typically the Event Registration record is changed to Registered by a managed trigger, when the associated Order is marked as “Paid”. But with my process flow turned on,  the Event Registration wasn’t getting changed to Registered, and the email wasn’t going out. I could go back and update those registrations manually, and everything that was supposed to be happening would then, in fact, happen.

I did some testing and reading the error logs, and found that the show-stopper was in my Invocable Method, and the error was:

System.VisualforceException: Getting content from within triggers is currently not supported.

Even though the Invocable Method was separated from the trigger by a process flow, the fact that it was getting called during the trigger’s operation was scuttling the email and the rest of the changes to the Event Registration.

There is online discussion about the error, and a solution – move the getContent() call into a future method, and then call that from within the class kicked off by the trigger. I didn’t want to restructure the code if I could avoid it, so I tried moving the Apex call in my process flow from an immediate action to the soonest available scheduled action. This worked – the Event Registration is properly updated to Registered status after payment, and then the email with my dynamic PDF goes out an hour later. This lag may not work for every application, but in this case, the delay isn’t a problem, and this solution saved considerable time over restructuring the code and testing. (One could also set a time via a formula field to reduce the lag to less than an hour, again with less effort than restructuring the code.)

Posted in Process Automation.

Leave a Reply

Your email address will not be published. Required fields are marked *