6

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?

Improve this question

2 Answers 2

Reset to default
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? :/

Improve this answer
5
  • 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 ♦
    Commented Aug 7, 2014 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
    Commented Aug 7, 2014 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 ♦
    Commented Aug 7, 2014 at 22:08
  • @sfdcfox do you have any updates on how or if you solved this problem? Thanks.
    – Matheus Gonçalves
    Commented May 16, 2018 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 ♦
    Commented May 16, 2018 at 20:00
1

This attribute was added in 2020. You can add renderUsingSystemContextWithoutSharing="true" to the messaging:emailTemplate tag to have the template disregard sharing and run in a system context. This has the potential to reveal data the recipient couldn't see otherwise so it's definitely something to use with care.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .