5

We have a workflow rule that triggers when ownership of a record changes and certain conditions are met-- part of the criteria is ISCHANGED(OwnerId), which causes the workflow to perform its actions. The action in question is to send an email notification to the new owner, which is done through a Visualforce template, because we'd like to control the output without the limitations of an HTML or text template.

When the ownership of the record changes from one user to another, it's entirely possible that the original user will no longer have access to the record. If this occurs, the email template crashes and rolls back the entire transaction. There's another question with a self-answer that would work, except we can't use sharing rules because that would expose data that can't be exposed to certain groups of users.

Of course, we could build our own email "template" and send it through code instead of a workflow, but this would reduce our ability to modify the template, as we have a two-month release cycle, and we can only deploy code changes during the regularly scheduled release cycle (an approximately eight hour window) without requiring approval from a dozen different managers-- configuration changes, such as email templates, aren't subject to this limitation.

So, getting back to the title: Can we enable a Visualforce template to not crash when sending an email on a record that the user no longer has access to?

1

Not the main template's body as it can't have a controller.

You can try moving your code to VF component and attach a controller to it. But I feel it'd work for other things related to the main record (when explicitly queried + without sharing), not when the main "relatedTo" becomes invisible...

It might even be that it's not the email template usage that fails. What if it's the act of trying to attach a completed Task to thing I can no longer see? :/

  • I just tried this. No dice. Coincidentally, removing all references to relatedTo allows the workflow to trigger successfully. The email is sent in this case. However, that defeats the purpose if we can't even include a link to the record. – sfdcfox Aug 7 '14 at 21:48
  • How about moving the logic to before update trigger? have a bit of code that sends it (you can still reuse your template with setTemplateId? Emails are sent out after transaction really commits (that's when the field history tracking gets written too) but maybe the content would be already "pre-merged"... – eyescream Aug 7 '14 at 21:58
  • We're trying to stick with a workflow. I'm prepared to use code if need be; if I can't solve this with either of the two questions I've posed, I'll be forced to use that solution. I've only four business days until code lock, so desperation may win out over a proper solution. I do appreciate you taking the time to brainstorm with me, though. As I posited originally, if we are forced to use code, we lose the flexibility of configuration-only changes. – sfdcfox Aug 7 '14 at 22:08
  • @sfdcfox do you have any updates on how or if you solved this problem? Thanks. – Matheus Goncalves May 16 '18 at 19:52
  • @toadgeek We ended up writing code. I was on a time limit and never had a reason to revisit this since. I might do some research (it's been ~12 releases since this question) so maybe the state of things have changed. – sfdcfox May 16 '18 at 20:00

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.