Apex Code Development You need to sign in to do that
Don't have an account?
JasonGabler 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.
thanks,
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.
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.