Salesforce How-To Educational Series #3: Process Builder

Here are quick tips for two things I did not know before I discovered them today…

Page layouts can cause Process errors

If you have a Process (built using Process Builder) that updates a field on an object, that field must appear somewhere on all of the Page Layouts connected with that object.

If you don’t follow this guideline, the Process may fail when an automated User (like your marketing automation system) tries to sync a bunch of records in a bulk execution request.

Your Salesforce org will send a cryptic error message:

CANNOT_EXECUTE_FLOW_TRIGGER: The record couldn’t be saved because it failed to trigger a flow. A flow trigger failed to execute the flow with version ID 301234567890ABC

Only the error message doesn’t get sent to you, the System Admin (as will happen when a Flow fails, for example). Instead, the error message gets sent to the error report in the outlying system. And the custodian of said system may not know how to interpret the error message or to know to send it to you.

Thanks to an answer to this question by NJ_Ray in the Salesforce Developer Community, I was able to identify that a Process in our org that runs on one object that updates a field on another object’s records that was not on one of the second object’s Page Layouts — a page layout I had created about a year ago, about 18 months after my predecessor created the Process.

The bad part is, when constructing a new Page Layout or modifying an existing one, you will have to know if there are any fields that are updated by by a Process. Because Process is so handy for doing cross-object field updates, the Process updating the fields on, for example, the Contact object, may actually be running on another object, Campaign Members, for example. This is going to get very hairy if and when Salesforce has us convert all Workflow Rules to Processes.

By the way, when I added the field to the page layout, I put it very unobtrusively down in the System Information section, and made the field Read Only on the page layout (can still be updated by API and Field Updates from workflow rules, Flows, and Processes).

View a Process As a Flow

As you may be aware, each Process is actually a Flow that your org constructs based on the design of your Process. On that post in the Developer Community, there was an answer from MythreyeeSS with a link that you can modify to view the Flow constructed from your Process. Here’s the sample link:

https://yourinstance.my.salesforce.com/designer/designer.apexp#Id=30116000000PPKL 

Just swap out your instance — “naX” or custom domain — and the version Id (like in the error message above) and voila! you can see your Process as a Flow. One thing I discovered is that Flow version IDs start with 300 and Process version IDs start with 301.

I would advise you to be very very careful when viewing a Process this way. For now, I wouldn’t try to edit my Processes using the Flow Designer — that’s what Process Builder is for! But this could be very handy for diagnosing a problem with a Process when you can see it from a different perspective.