function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
KevinShukKevinShuk 

New opportunity save behavior and workflow rules - bug found?

Hi all,

 

Like most of you, I'm aware of the recent changes to opportunity save behavior where changes to products cause workflow rules, triggers, etc on the parent opportunity to be evaluated again. Regarding workflow rules, my understanding is that they will be evaluated more often, but that the resultant actions are still subject to the evaluation criteria as well as the rule criteria. 

 

Here is the scenario - a workflow on an opportunity has the eval criteria of "When a record is created, or when a record is edited and did not previously meet the rule criteria." The rule criteria are "StageName equals Closed Won", "Opportunity Name does not contain Test" and "Account Name does not contain Test"

 

When an Opportunity is moved to Closed Won, and neither it not its account have "Test" in their names, then the rule evaluates and the actions fire - this much is correct. 

 

The problem is that if the pricebook is changed, the rule will not only be evaluated again, but the actions will fire again even though the rule criteria have previously been met, and switching pricebooks does not visibly affect the rule criteria. Further, adding or changing products on this opportunity does not cause the rule actions to fire again, nor does editing the opportunity itself, say, changing the description. Only changing pricebooks causes the behavior I describe.

 

This behavior feels like a bug because the events are contrary to the eval criteria of,  "When a record is created, or when a record is edited and did not previously meet the rule criteria," because the rule criteria have already been met and the edit in question does not seem to affect those criteria.

 

I'm going around with SFDC support on this, and we're still at the stage where the analyst looking at this issue is confusing rule evaluation with the actions firing. They're initially blaming this on the new oppty save behavior, but I don't think that explains the whole issue. So, I pose the question to you: I say it's a bug - what do you think? 

Ispita_NavatarIspita_Navatar

You can probably have a small workaround for this in the evaluation criteria add the following to your already existing criterion:-
OR(ISCHANGED(Stagename),ISCHANGED(AccountName),ISCHANGED(OpportunityName))

So if you had:-
say And ( ( AccountName<> 'test' ) , ( OpportunityName <> 'test'),StageName='Closed Won' ) -  now it will be as follows:-

AND( And( (AccountName<> 'test'),(OpportunityName<> 'test'),StageName='Closed Won') , OR(ISCHANGED(Stagename),ISCHANGED(AccountName),ISCHANGED(OpportunityName)) );

 

Did this answer your question? If not, let me know what didn't work, or if so, please mark it solved.

thunksalotthunksalot

I have run into this exact issue and am very surprised to find that it has not been fixed nearly a year after it was pointed out here.  The fact that the proposed workaround involved manually performing the check that the built-in SF Evaluation Rule is *supposed* to be doing, leads me to conclude that this definitely is a BUG! 

 

Given that a fix hasn't come after nearly a year, I guess I'm going to have to move on and implement this work-around, which is very unfortunate because it adds a whole layer of complexity and room for error when working with an organization that has dozens of workflow rules related to Opportunities.

 

One thing that would make the workaround significantly less troublesome would be if there were a way to check for ISCHANGED(Pricebook).  Is there any way to do that?  If so, the workaround could simply be:

 

AND( And( (AccountName<> 'test'),(OpportunityName<> 'test'),StageName='Closed Won') , NOT(ISCHANGED(Pricebook)) );

 

KevinShukKevinShuk

Actually, it is not a bug according to Salesforce, it is expected behavior. Still feels like a bug, but whatever.

 

ISCHANGED and PRIORVALUE are not solutions per se because they only work with a workflow that is not evaluated every time a record is changed. 

 

However, this could be a solution if the workflow is written with the idea that it will fire every time the record is edited, and the criteria narrow down to evaluate true only in the specific instance where we want it to fire.