A flow trigger failed to execute: The mystery error

The Lightning Process Builder has been GA for a little over a year now. For the most part, it is a fantastic tool. Administrators have been able to build some pretty amazing workflows without the need for a developer like myself. The biggest annoyance that I have seen, though, is that pesky undescriptive error message that shows on the top of the page when something goes wrong.

It might as well say “Sorry. You broke it. Try something else.” Furthermore, it advises the end user to see the “administrator.” The administrator the message is talking about is the admin user who created the process. Whenever an exception is thrown, Salesforce sends the exception detail email to the process creator. So if that person is away on vacation or just out of office, you are out of luck. I don’t know too many administrators who can understand this cryptic message without the exception email. That’s why I am writing this blog. I want to empower you, the noncreator-of-this-process administrator (or developer), to be able to quickly find out what is going on when that email is inaccessible.

Before we dive into how to quickly determine what actually went wrong, let’s get our hands dirty with what the process builder is actually doing. Before the Lightning Process Builder, we had, for a very short amount of time, something called “Headless Flow Triggers.” It was pretty simple. You would build a regular workflow and one of the workflow actions was “Flow Trigger.” Then you could pick a headless flow (a visual flow with no screen elements) to fire when the workflow rule evaluated true. Then in Spring ’15, the Lightning Process Builder came along as the replacement for flow triggers. In the background, the process builder is creating a hidden “headless flow.” That means when you build a Lightning process, SFDC creates a headless flow that is just not accessible in the setup. It is, on the other hand, still viewable with url hacking.

Onward! First step is to figure out which process broke during the update. You may have noticed that 18-character id in the error message. That id is the flow version id of the process. The prefix “300” is a flow definition id and “301” is a flow version id. In the picture above, the flow version id is “301360000002M3V.”

Now, take that id and go to Setup > Create > Workflow & Approvals > Flows. Then open up any flow; doesn’t matter which one. If your org does not have any existing flows, just create a new one. Once the flow is open, the URL should look something like, “https://na30.salesforce.com/designer/designer.apexp#Id=30136000000TPen”. Do you see that “301” prefix in the URL? Now replace that id with the id from the error message and go to that url. Now here’s the trick: You have to go to that url again. (Typically I click in the URL again and hit enter) Now, the flow designer will update to the new flow version. In the top left of the screen once the page has loaded, you will see the name of the process that the version id is for.

Now that we have the exact process that is failing, we can look deeper into the issue. Go to that process to determine what it is trying to do. If nothing seems out of the ordinary, we will need the debug log to look deeper. Turn on the debug log with a Log Level that has “Workflow” set to “Finer.” Replicate the flow error and open the log. (Sidenote: the log would typically show in red if an error occurs, but, of course, it does not for process errors.) Once you have the log open, click Cmd+F (Mac) Ctrl+F (PC) and search for “FLOW_ELEMENT_ERROR.” That will show you the error that is actually being thrown.

As you can see in this example, there is a validation rule that is failing and that is causing the process to fail. Voilà!

Hopefully at some point Salesforce will make an update to this error message to actually display the error but until then, this has been the best debugging technique that I have found when the exception email is unavailable.

Cheers!