Struggle to understand reevaluation of workflow rules

While discussing about workflow rules, I think it is also better to discuss about process builder and compare it.

Here is my testing on both workflow and process: (having re-evaluate workflow and re-evaluate enabled in process)

In a new dev org, have 3 picklist fields with options:

1. pl1 - 1op1,1op2,1op3

2. pl2 - 2op1,2op2,2op3

3. pl3 - 3op1,3op2,3op3

Implement 3 workflow rules as below:

1. Trigger if pl1==1op1. Do field updates as pl2=2op1 and pl3=3op2

2. Trigger if pl2==2op1. Do field updates as pl3=3op1 and pl1=1op2

3. Trigger if pl3==3op1. Do field updates as pl1=1op1 and pl2=2op2

If you observe above pattern, its infinite loop.

Here is how workflow rules has triggered when I updated pl1 to 1op1 from 1op2:

-----record update
-----1st workflow triggered
-----2nd workflow triggered
-----3rd workflow triggered
------------------------done - no more workflows triggered

So, there was 4 trigger cycles (before+after update trigger).

According to the point Only workflow rules that didn’t fire before will be retriggered - the 3rd rule didnt trigger the 1st rule as it was already fired once.

Regarding the 2nd point, I was not able to achieve it with multiple combinations of field changes and workflow rules changes.

For Process Builder:

Implement 3 processes in same way as above.

1. Trigger if pl1==1op1. Do field updates as pl2=2op1 and pl3=3op2

2. Trigger if pl2==2op1. Do field updates as pl3=3op1 and pl1=1op2

3. Trigger if pl3==3op1. Do field updates as pl1=1op1 and pl2=2op2

The 2 field updates are 2 different immediate actions in each process.

Here there were 22 trigger cycles. So, it was not possible to understand what was happening. This number 22 is huge. Surprisingly, there were 21 SOQL queries, 21 DML statements, 21 query rows, 21 DML rows consumed (but none in workflow rules).

Now I have deactivated 2 processes and let only 1st process active. Here are the results:

-----record update
-----1st immediate action * 6 cycles
-----2nd immediate action * 6 cycles

So, total of 13 trigger cycles. Incidentally 12 SOQL queries, 12 query rows, 12 DML statements and 12 DML rows. If you notice here, it was 2 immediate actions * 6 cycles + 1 (record update).

Now, I have modified that process to have both field updates in 1 immediate action. Now,

----record update
----process trigger * 6 cycles

and 6 SOQL queries, 6 query rows, 6 dml statements and 6 DML rows.

Whatever we do, if criteria matches the trigger is run 1 record update trigger + (6 * Number of processes * Number of immediate actions). If no criteria is selected, its triggered everytime.

Finally, although well known about this difference - workflow rule triggers ONLY if pl1 value is changed from some other value to 1op1. But process builder triggers as long as the value of pl1 is 1op1.

2. Make sure that your workflow rules aren’t set up to create recursive loops. For example, if a field update for Rule1 triggers Rule2, and a field update for Rule2 triggers Rule1, the recursive triggers may cause your organization to exceed its limit for workflow time triggers per hour.

The key to understanding this is that Rule1 and Rule2 must both be Time-Based Rules. That's how these two rules can become recursive and cause your org to exceed the limit for workflow time triggers per hour.

There are additional considerations that are also important. Time based workflow isn't triggered down to the second or even the minute as you might expect. Instead, it executes in batches as groups of records several times per hour. This can have unexpected consequences you may not have anticipated when writing rules. You can suddenly find yourself hitting a 10 callouts per request limit when a group of records are batched together and you have asynchronous operations being called that you wouldn't normally see in your Org's usage patterns.

You're limited to 1000 time based workflow triggers per hour. If 1400 of them try to execute, 400 of them will be held until the next 1 hour period. Remember that time based workflow is always reevaluated before it is executed. For that reason, it can often execute when you don't expect it, such as when a record is edited to meet the criteria.

For more on this, you might find the following links useful: Time-Based Workflow: Apex Trigger Processing and Governor Limits,Considerations for Time-Dependent Actions and Time Triggers, and Monitor Pending Workflow Actions.