OK, I'm going to leave this page here, but lesson learned. After all this debugging it was NOT a technical issue it was a process issue. Well, the debugging allowed me to work out that it was NOT a technical issue, so go back to the very basics. Draw out the steps on paper. My process was doing this: - If the status is X then
- Email the contact.
- Set the status to Reset
- Set the field to say the email has been sent (to prevent further loops).
Then there was another workflow - If the status is Reset
- Delete the link to ObjectA (clear the field with the lookup to ObjectA) - not the best thing to be doing, but it was a bit of a hack workaround for another issue rather than changing some very complex custom code that no one knows much about (yes, we do have it on the roadmap to rebuild this code).
So, what was happening? Because you can't guarantee the order of execution, it seems that the link to ObjectA was deleting before the email was sent.
When the workflow was first built, there was a 1 hour gap between the email sending and the status being set to reset, so in quickly reconfiguring the workflow I did not twig that the order of execution problem would exist.
| Panel |
|---|
EDIT AGAIN! OMG How stupid am I, it is NOT an issue of order of execution at all! (I worked this out after another 2 hours of trying to split the workflows into smaller chunks and still it was not working, but as soon as I edited the record it was working. DOH! Stupid Stupid Stupid! The one thing I did not mention in this post yesterday, (and would have helped me if I had mentioned it, because I would have spotted the issue right away) is that the process that triggers this email is done on a public Site. (ALL of my other emails are triggered from internal processes). Now, if I had built this public site myself, I would have probably guessed this a lot earlier. I googled visualforce email fields external sites user and found this post http://salesforce.stackexchange.com/questions/76078/email-alert-fails-with-sites-user-insufficient-access-or-readonly-user-does-no Of course it's a permissions issue! Of course! And as soon as I knew that it took 15mins to fix and test then another 15 mins to delete all my testing artefacts. Job done! |
So lessons learned: - Is it a technical issue - eg is it something that Salesforce just won't do or you've hit limits - there should be something if you google - I found nothing.
- Is it a data issue - I tried re-creating the data from scratch to recreate this with a new set of data - still had the issue.
- Is it a permissions issue - if only I had tried that first!
- Are there red herrings that lead you down a rabbit hole? - I think the custom fields vs standard fields are a red herring, but I can't be sure. Watch out for those rabbit holes! Set some time limits.
- Find another way to do it - For me, trying it from the other object was the turning point - because other emails work from that object, so it could not be technical.
- Simplify the workflow - I had a complex workflow so I had to try to simplify it - does it work if I just send the email on every update of the record? This is how I eventually found the problem.
|