Return to Answer

added 16 characters in body

Source Link

edited Apr 30, 2013 at 18:11

The behaviour described in your "Update 1" sounds to me like some kind of security flaw that SF might decide to fix in future. I'm not sure I'd count on something like this in a production-ready functionality. Maybe simply raise a Case with support whether it's intended behaviour?

If it's acceptable to just fire the email as is (without user being able to preview & modify the body) maybe you can experiment with adding &save=1 to the URL. Still - a determined user might inspect the source of the button and learn the template id.

You could also consider a "do it yourself" solution with a bit of Apex? Both single and mass email objects have setTemplateid() method you could use. You can query the EmailTemplate object for IDs.

rtype=003&p2_lkid={!Opportunity.AccountId}& template_id=00X60000001euod

to

    /00X60000001euod

(no idea if it'd give them "insufficient privileges").

The behaviour described in your "Update 1" sounds to me like some kind of security flaw that SF might decide to fix in future. I'm not sure I'd count on something like this in a production-ready functionality. Maybe simply raise a Case with support whether it's intended behaviour?

If it's acceptable to just fire the email as is (without user being able to preview & modify the body) maybe you can experiment with adding &save=1 to the URL. Still - a determined user might inspect the source of the button and learn the template id.

You could also consider a "do it yourself" solution with a bit of Apex? Both single and mass email objects have setTemplateid() method you could use. You can query the EmailTemplate object for IDs.

If you have power users that are determined enough they might still be able to navigate to the template by shortening the URL from
```
 /email/author/emailauthor.jsp?retURL=/{!Opportunity.AccountId}&
```

rtype=003&p2_lkid={!Opportunity.AccountId}& template_id=00X60000001euod

to

    /00X60000001euod

(no idea if it'd give them "insufficient privileges").

The behaviour described in your "Update 1" sounds to me like some kind of security flaw that SF might decide to fix in future. I'm not sure I'd count on something like this in a production-ready functionality. Maybe simply raise a Case with support whether it's intended behaviour?

If it's acceptable to just fire the email as is (without user being able to preview & modify the body) maybe you can experiment with adding &save=1 to the URL. Still - a determined user might inspect the source of the button and learn the template id.

You could also consider a "do it yourself" solution with a bit of Apex? Both single and mass email objects have setTemplateid() method you could use. You can query the EmailTemplate object for IDs.

The behaviour described in your "Update 1" sounds to me like some kind of security flaw that SF might decide to fix in future. I'm not sure I'd count on something like this in a production-ready functionality. Maybe simply raise a Case with support whether it's intended behaviour?

If it's acceptable to just fire the email as is (without user being able to preview & modify the body) maybe you can experiment with adding &save=1 to the URL. Still - a determined user might inspect the source of the button and learn the template id.

You could also consider a "do it yourself" solution with a bit of Apex? Both single and mass email objects have setTemplateid() method you could use. You can query the EmailTemplate object for IDs.

Source Link

created Apr 30, 2013 at 16:57

If you have power users that are determined enough they might still be able to navigate to the template by shortening the URL from
```
 /email/author/emailauthor.jsp?retURL=/{!Opportunity.AccountId}&
```

rtype=003&p2_lkid={!Opportunity.AccountId}& template_id=00X60000001euod

to

    /00X60000001euod

(no idea if it'd give them "insufficient privileges").

The behaviour described in your "Update 1" sounds to me like some kind of security flaw that SF might decide to fix in future. I'm not sure I'd count on something like this in a production-ready functionality. Maybe simply raise a Case with support whether it's intended behaviour?
If it's acceptable to just fire the email as is (without user being able to preview & modify the body) maybe you can experiment with adding &save=1 to the URL. Still - a determined user might inspect the source of the button and learn the template id.
You could also consider a "do it yourself" solution with a bit of Apex? Both single and mass email objects have setTemplateid() method you could use. You can query the EmailTemplate object for IDs.