Considerations for Using Visualforce Email Templates with Guest Users

Review these considerations when using Visualforce Classic email templates to send emails to guest users.

Available in: Salesforce Classic and Lightning Experience

Available in: Essentials, Enterprise, Performance, Unlimited, and Developer Editions

When renderUsingSystemContextWithoutSharing="True", the email template runs in system mode, which bypasses user permissions, field-level security, and organization-wide defaults. Be careful when using this setting so that you don't inadvertently expose sensitive data. Before using this setting, assess the impact of the guest security policy and, if necessary, update the Visualforce email templates instead.
Sending a test email using a Visualforce email template doesn’t accurately represent the email that a guest user receives. Instead, access your Experience Cloud site as a guest user and initiate sending an email the way a guest user does.
Imagine that you’re testing an email template to recover passwords. Create an Experience Cloud site user with your email address. Then go to the site as a guest user, click the Forgot Password? link, and enter the name of the user you just set up.
When sending a Visualforce email template to a guest user, these global variable values have different values.

Global Variable	Expected Output for Guest Users
`$Api.Session_ID`	`NULL_SESSION_ID`
`$Cache.Session`	`Session not found - Session Cache not supported`

When sending a Visualforce email template to a guest user, checking an object’s accessibility using $ObjectType returns these output values. The returned value is false even though you can access that object in system context.
If you know that you have access, ignore the returned value.

$ObjectType Global Variable Attribute	Expected Value for Guest Users
`accessible`	`false`
`createable`	`false`
`deletable`	`false`
`mergeable`	`false`
`queryable`	`false`
`searchable`	`false`
`undeletable`	`false`
`updateable`	`false`

Checking the value of a permission (for example, using $Permission.canSeeExecutiveData) always returns false. The returned value matches what Apex returns when you check a permission in system context.

Did this article solve your issue?

Let us know so we can improve!

Product Area