Sites and the hidden Profile has been a leader in the SaaS and PaaS markets since those buzzwords were coined, though as a web developer my interest was piqued with the advent of Sites. For the uninitiated, Sites is a feature of the cloud computing platform that allows a developer to create a publicly available web site or application with a completely custom UI. The native look-and-feel of is great for a broad category of business applications, but Sites allows you to shoot for the moon with your user experience.

Sites builds on’s native capabilities, allowing developers to use powerful technologies like workflow and fine-grain security controls without building them from scratch. Since most organizations will need to enforce some level of data security, it’s worth exploring how that intersects with making information available to the public.

The hidden Profile

If you’ve worked with for any length of time, you’ll no doubt be familiar with the concept of a Profile. Essentially, a Profile is a set of privileges which can be granted to multiple users to avoid the grunt work of configuring security on a user-by-user basis. A detailed discussion of Profiles is beyond the scope of this blog post, though they are documented extensively elsewhere. Sites also leverages the concept of a Profile to determine which pieces of data are visible on a given web site, though it’s not immediately obvious that this Profile is hidden. To be more specific, a new Profile is created automatically by the platform when a new Site is created. The name of this Profile is the site’s Label, followed by the word “Profile” (as shown below):


Site configuration

When viewing the list of Sites configured for your org, click the Site Label to view the screen above. From there, click Public Access Settings to view the details of the hidden Profile.


The Profile generated automatically for that site

The name of the Profile is worth noting, especially when it comes time to deploy the site to a production org. Configuring a Profile can be a bit tedious and error prone, so once this is done correctly in a sandbox, it’s convenient to migrate this configuration rather than rebuilding it. When migrating with Eclipse, this hidden Profile will appear in the list of objects that can be deployed to another org, but it is not shown on the list of Profiles viewable under Setup in the web UI.


The new profile is missing from this list

This simple fact can make the security configuration of a Site somewhat confusing, but once you become familiar with it, the mystery goes away. The fact that this Profile is hidden is beneficial for large organizations that have many individuals administering a single org, not all of whom may understand the purpose of every Profile.


It’s not uncommon to get tripped up by security configuration issues when beginning to work with Sites. The key is to simply configure the hidden Profile correctly in a sandbox, then migrate that profile to production rather than rebuilding it by hand.