Active Workflow Rules limit exceeded? - Process Builder is the savior

I am back with this blog on my initial analysis on “Active Workflow Rules limit exceeded” workaround. They(vis-à-vis the relevant important points) are enumerated below.

We have two options. They are:

Either follow #1* below; increase the limit to 300. Further new Workflow Rules/Actions to be accomplished through Process Builder highlighted in #2** below.

OR

Identify which existing WF rules could be migrated to Process builder considering  #2** below.

·         #1* By default, each object (or entity) is limited to 50 Active Workflow Rules. If you need more, you can request an increase of up to 300 Active Workflow Rules.

·         #2** Post Salesforce Summer ’16 Release Notes, Process Builder  can execute multiple action groups at one time, giving you more ways to automate your business and manage everything in one place.

o   Meaning?

Now you can choose what happens after your process executes a specific action group. Should the process stop, or should it continue evaluating the next criteria in the process?

It’s up to you! Best of all, executing multiple action groups in a single process makes it easy to manage all of your processes for a given object, like a Case, in one place.

With this release, I think Salesforce is trying to encourage "One Process Builder Per Object" which is analogous to “One Trigger per Object” design pattern.

·         Some important limits:

o   Total number of criteria nodes in a process  - 200

o   Total number of criteria nodes that are evaluated and actions that are executed at runtime - 2,000

·         Process Builder Design Considerations

o   If you create processes to replace other setup entities, such as a workflow rule, or an Apex trigger, make sure you delete those entities when you activate the equivalent processes.

Otherwise, both workflow and processes will fire and cause unexpected results, such as overwritten records or redundant email messages.

o   Actions are executed in the order in which they appear in the Process Builder.

o   If any of the actions fail, the entire transaction fails and an error message displays.

·         Process Builder Scheduled Actions Considerations

o   If an action group contains scheduled actions, you can't continue evaluating the next criteria in your process after executing those actions.

o   2 ways as per my perspective:

§  First, create separate process builder for Scheduled Actions, OR

§  Second, keep the scheduled action in the last node of the same process builder so that there is no question of evaluating next criteria node.

·         What more I did

o   In my sandbox, I tried to validate if Process Builder has functions available to satisfy the existing Workflow rule criteria because there are certain limitations on usage of few functions in process builder.

·         Next Step

o   Identify which WF rules need to be migrated.

o   To start creating a TEST Process Builder to see how does it behave(to find any unexpected behavior) and how we can accommodate/migrate most of the existing Workflow Rules into it.

Note: These are just a analysis report prepared w.r.t. SFDC Summer '16 release notes.  Efforts have been made to simplify the concept.