Salesforce Sites Considerations
Before you create and use Salesforce Sites, review considerations around App Exchange packaging, access and authentication, and potential URL conflicts between sites.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: Developer, Enterprise, Performance, and Unlimited Editions |
Packaging
Sites aren’t packageable. However, you can package sample code, Visualforce pages, Apex classes, or components for a site using a managed package.
To install unmanaged packages that contain Visualforce pages or Apex classes that refer to a site, Salesforce Sites must be enabled.
Access and Authentication
You can grant Read and Create permissions on all standard objects except products, price books, and ideas. Also, you can grant Read, Create, Edit, and Delete permissions on all custom objects. For additional access, you must authenticate site visitors as portal users.
Custom authentication isn’t supported. Only these methods are supported for Salesforce Site authentication.
- Customer Portals—enable public login and registration
- Partner portals—create partner users
URL Conflicts Between Sites
If you host multiple sites on the same Salesforce-managed domain, be sure to review your site URLs for conflicts, as it’s possible to configure the same URL for pages on two different sites.
Let’s say you use https://SitesSubdomain.force.com for Site A’s homepage, and https://SitesSubdomain.force.com/products for Site B’s homepage. If you create a page on Site A that uses the subpath /products, that page and Site B’s homepage both use the URL https://SitesSubdomain.force.com/products.
In this scenario, a site visitor can only access the Site A page through a navigation menu on Site A. If a site visitor navigates to https://SitesSubdomain.force.com/products any other way, they’re directed to Site B’s home page.
