+ Start a Discussion

New/edited contact workflow triggered when changing contact's account... work around?

I've recently encountered the phenomenon in which new/edited contact workflow rules are triggered when moving a contact record from one account to another.  I'm surprised I have not noticed this before.    I was updating contacts via the Web API, changing their account affiliation, and to my surprise some e-mails were sent out because a workflow that triggers on "When a record is created, or when a record is edited and did not previously meet the rule criteria" for contacts" fired off.  I also saw that just changing an contact's account within Salesforce (using the web UI) has the same effect.


I assume this means that "new contact" in Salesforce means "contact is new to an account"?    


Is this true?  Is there a way to keep such workflows from firing?   I can assure you that the rule criteria has nothing to do with the contact's account.  Such a change should not be firing the workflow.




Jason Gabler


Are you sure there's not perhaps some other workflow or an Apex trigger that's changing something on the Contact such that the contact does in fact meet the criteria when it didn't before?  Try turning on Setup | Monitoring | Debug Logs and then change a contact's account via the UI.  It's kind of like reading the green characters on the Matrix screen, but if you can make sense if it it can help you.  You'll get a trace of everything that happened, and maybe it'll clue you into why your workflow is firing. 


Thanks for the reply.   I followed your suggestions and am still stumped.  I was able to wade through the Matrix screen (its not too bad, really :).  I see where the criteria evaluations are  true (WF_RULE_EVAL_VALUE|1 and WF_CRITERIA_END|true).    These criteria evluations would be correct except that  1) the record is not new and 2) that the changes involved are unrelated to the given rule criteria. 


Here's the situation.  The rules which cause the workflow to fire have:


Evaluation Criteria: When a record is created, or when a record is edited and did not previously meet the rule criteriais created, or when a record is edited and did not previously meet the rule criteria


Rule Criteria:  Contact: SomeCustomCheckboxField EQUALS True


The only thing changed is the account name and the workflow fires off. So the record did not change with regard to meeting the criteria, or not. And, it is not a new record.


Any further insight would be appreciated.


Jason Gabler


[EDIT]  I just tried changing the phone number instead of account name.  No workflow rules fired.  I'm telling you, there's something special about changing a contact's account.


Well, I tried it myself, and in fact I got the same result: if the contact had previously matched the criteria and then you change its account, the workflow fires again.  Interesting.  I can't think of any good or logical reason why that would happen; it may be a bug.


Maybe you could change your workflow criteria to a formula and add NOT(ISCHANGED(Account)) ?  That's the only thing I could think of that could counter this.


I just spoke with Salesforce support.  Honestly, I'm not sure I got the concepts across.  At the end of the conversation the support tech said authoritatively that contact record creation and moving a contact record from one account to another are both considered as contact creation event, at least with regard to workflows. However,  we got to the point in a way that left me wondering how correct that truly is.


While I can understand the idea that a contact record being "new" and "new to an account"  have a semantic relationship, it seems to be a bad idea, to me, to have no way to differentiate between those two types of events.


Now, having laid out my complaint,  I do realize that one could have some sort of age-based criterion on a workflow rule to see if the contact is genuinely new.  For example,  test on the records 'created date'  to be older than 10 seconds.  Its still a bit of a subjective test, however unlikely it is that it would produce incorrect results.

Very old question and comments I know but I've just come across this 'phenomenen' too.... very strange behaviour. Had me pulling my hair out for a little while to be honest.
Brynn BellinghamBrynn Bellingham
I'm now having this same issue.... A 'only run when eval becomes true' is working great for sending out welcome emails to new members... until someone changes housholds or needs to be housed under a new account for some reason. Very frustrating.
Yosef Eidensohn 12Yosef Eidensohn 12
We are now just days short of 2021 and this issue is still happening. Just came accross it our org. Has anyone created a known issue out of this? BTW the workaround of using NOT(ISCHANGED(Account)) as *werewolf* mentioned back in 2011 does not work unless you set the workflow cirteriea to "created, and every time it's edited". May have to go with process builder or flow here. 
An easier workaround might be to just add a condition to the workflow that the "timestamp_field_c=null". this will allow the timestamp to only get populated once and once only.