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.
