3

I have a workflow rule that fired unexpectedly.

The workflow rule was set to evaluate when a record is created, and any time it's edited to subsequently meet criteria

The workflow rule criteria are:

  • Case_Worker__c != null
  • Type != Billing
  • Case Owner = Customer Care (a queue)

This workflow rule fired (causing an email alert to be sent out to some of my company's customers) when I had my intern update the ContactId on the Case, with no other fields being changed

I was able to reproduce this behavior myself (after making sure that no more of these emails were erroneously sent off to our customers). I was also able to reproduce this issue when updating the AccountId field on the same Case record.

After I narrowed the cause down to this workflow rule, I took a look at my org's Case Assignment Rules and Case Auto-Response Rules and found nothing that would be setting or overwriting any of the 3 fields included in the workflow rule's criteria.

Why do updates to ContactId or AccountId cause this workflow rule to fire?

Edit:

I also checked the 2 triggers I have on Case (these triggers were inherited, moving everything to my trigger framework is work for my downtime). The only Case field updated in my triggers is Parent_Account__c.

After that, I checked every other trigger in my org, as well as every apex class in my org. I was unable to find any instance of any of the 3 fields used in the workflow criteria being altered.

Edit 2:

Here's a minimum viable reproduction.

The prerequisites are:

  1. Have at least 2 different Contacts in the org you are testing this in
  2. Have no mandatory lookup filters on the Contact Name (ContactId is the API name) field. Alternatively, ensure your 2 contacts will meet a mandatory lookup filter
  3. Have no existing workflow rules on Case that contain workflow field updates which update the Contact Name (ContactId) or Web Email (SuppliedEmail) fields
  4. Comment out any portions of triggers or apex that update the Contact Name/ContactId or Web Email (SuppliedEmail) fields
  5. Double check that Case Assignment and Case Auto Response rules won't interfere with the Contact Name/ContactId or Web Email (SuppliedEmail) fields

After that is done

  1. Create a new workflow rule on Case
  2. Set evaluation criteria to Evaluate the rule when a record is created, and any time it's edited to subsequently meet criteria
    • Set the rule criteria to Case:Web email equals admin@localhost.com
  3. Create a new workflow field update (immediate action)
    • Set it to update the Description field of Case
    • Use a formula Description + 'Last workflow field update at: ' + TEXT(NOW())
  4. Don't forget to activate the workflow rule
  5. Either create a new Case, or use an existing one
  6. Populate the Contact Name (ContactId is the API name) field
  7. Update the Web Email (SuppliedEmail is the API name) to admin@localhost.com
  8. Observe that the Description field has been updated
  9. Update the Contact Name field
  10. Observe that the Description field has been updated again, even though the Web Email field has not changed
  • 1
    Seems reasonable a trigger might update Case Worker in that scenario? – Adrian Larson Jul 22 '16 at 19:42
  • 1
    Forgot to mention that I went through all of my triggers to check for updates to any of these 3 fields, I'll edit that in. – Derek F Jul 22 '16 at 19:44
  • I can give it a quick shot. I finished my work week a few hours ago. So, if my quick MVR doesn't work out, I won't get back to this until sometime on Monday (I'm in UTC - 6 land) – Derek F Jul 22 '16 at 23:48
  • 1
    @AdrianLarson MVR is up. There are some hoops to jump through, but those hoops are necessary to avoid other potential influences. – Derek F Jul 23 '16 at 0:23
  • @cropredy That's valuable real-world experience right there! In all seriousness though, this intern's big project is working on de-duping our Contacts. Updating the ContactId on Case is one of the last steps in the procedure I wrote for my intern to follow. We were doing a test run in our QA environment. I immediately took responsibility for the issue. – Derek F Jul 23 '16 at 15:53
5

By some amount of luck, I was able to do a Google search that led me to the Workflow considerations page on help.salesforce.com.

On that page is this gem

Workflow rules are triggered when a standard object in a master-detail relationship is re-parented, even if the object's evaluation criteria is set to Evaluate the rule when a record is: created, and any time it’s edited to subsequently meet criteria.

The only issue is that the ContactId field on Case is a lookup relationship (verified by looking at the standard Case fields in Salesforce proper, and through the apex workbench) instead of a master-detail relationship.

Despite that, standard lookups in Salesforce can show some unusual, albeit documented, behavior. The relationship type between OpportunityLineItem and Opportunity is technically a lookup relationship, and yet we can create rollup summary fields on Opportunity summarizing OpportunityLineItem records. We can also roll up fields from Opportunity records on Accounts (AccountId on Opportunity again being a lookup relationship)

So the only answer that I can arrive at is that, while the ContactId field on Case is a lookup field, it's treated by Salesforce as meh, close enough I guess... when it comes to ignoring the subsequently part of the any time it’s edited to subsequently meet criteria workflow evaluation setting.

As mentioned in the question, this appears to be the case for the AccountId field on Case as well. I haven't tested this with any other standard relationship fields on other standard sObjects.

  • Are you able to do rollup summary fields through this relationship? That would certainly lend credence to your theory. – Adrian Larson Jul 22 '16 at 20:50
  • 1
    I thought I tried this, but I wasn't sure...so I just attempted to create a rollup summary field on Contact summarizing a field on Case, and I cannot create the field. – Derek F Jul 22 '16 at 23:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.