With the Summer ‘13 release of Salesforce Communities, we’ve started to provide our customers with a powerful set of tools to engage people outside their organization: consumers, customers, prospects, resellers, partners, integrators, dealers, and other constituencies. But every business has a unique set of constituencies with a unique set of needs. Our legacy partner and customer portals were largely used as vertically-oriented process portals: they were set up for a specific purpose (customer self-service, origination of high-touch service, and channel pipeline tracking), and the primary engagement tools involved either maintenance of data and process (logging cases, registering leads, etc) as well as searching for relevant information to resolve issues or to accomplish a specific purpose (knowledge, content). And although the communities technology starts with the familiar setup and configuration of portals, adding great collaboration tools like Chatter, Ideas, and Q&A and powerful web content capabilities from Site.com takes Salesforce Communities from a simple process portal and makes it into a powerful engagement platform.

The addition of these tools also creates more choice for those looking to create a unique and engaging experience for their constituencies.

Containers: Where does Your Community Live?

When deploying a community, our customers must decide up-front what will drive the experience in that community: the traditional Salesforce tab paradigm, a custom interface built programmatically using Visualforce, or a custom interface built declaratively using Site.com. We refer to these options colloquially as containers. Simply put, a container can be thought of as the top-level architectural choice for how to drive pages in a Salesforce Community. Choice of a container determines not only how pages are built, but also how a community is branded, how native page functionality is treated (as of Winter ‘14), and the extent of the customizability and mobile strategy of a community.

Choice of a container, in some cases, may not be mutually exclusive. In any case, the initial choice of a community container has profound impact on many aspects of a community: how it’s built, who can make changes, its mobile strategy (including the ability to implement a responsive design), reuse of existing assets (such as Visualforce pages and native layouts), and the strategy for data-driven pages. This post is intended to help guide you through those choices, and their implications.

As of the Winter ‘14 release, Salesforce Communities provides three main choices of a community container:

The Communities (Tab) Container:

Salesforce started as a tab container. In the force.com platform, administrators define tabs and those tabs make up applications (Sales Cloud, Service Cloud, custom apps, etc). Similarly, a community running on the Communities (Tab) container is set up as a group of tabs. This is the default setting for a community when it is created. Upon configuring the community, an administrator simply chooses to use the regular Salesforce.com tabs to drive navigation in the community:

When using the Communities Container, one uses static files, managed under the Documents tab, to drive the look and feel of the header and footer area. This makes it possible to insert your company logo, the global search form, and other arbitrary content into every page in your community.

The Site.com Container:

Site.com can be used to drive the entire community experience, from head to toe. This is initiated by using the Branding page of the Community Setup screens to select the “Use Site.com to create custom community pages” option:

Screenshot of the Branding page of the Community Setup screens. Select the “Use Site.com to create custom community pages” option

You can then create pages in the Site.com studio associated with your community, set up an authorization scheme (allowing pages and assets to be public or private), and designate a default home page for the community:

Screenshot showing where to designate a default home page for the community

Site.com is a powerful way to drive simpler communities focused on self-service, responsive design, and quick iteration. The studio allows business users to very quickly create pages, alter content, and publish changes without IT intervention.

The Visualforce Container:

When deploying a community, you can choose to use Visualforce to drive the entire community experience. Instead of using the tabs configured in the Communities settings pane, it’s possible to have Visualforce take over the entire community experience from the point of user entry. This approach gives you programmatic control over every aspect of markup that’s rendered in the community. This allows you a wide degree of latitude to customize your community, and makes it possible to integrate responsive design libraries, external widget frameworks, and other innovative examples from the web.

Note that there is no specific setting to use Visualforce in a community, but this can be accomplished by taking a few steps:

1. Create a Visualforce page that uses the following attributes:
standardStylesheets=”false” Screenshot of a Visualforce page

2. Navigate into Setup and enter the settings for the Force.com site associated with the community:
Screenshot navigating into settings

3. Edit the site and set the Active Site Homepage to your new Visualforce page: Screenshot showing where to set the Active Site Homepage

NOTE: The Active Site Homepage is the first page users hit when they enter a community. When a community is first created, this field is automatically populated with a Visualforce page whose controller automatically redirects the user to the default communities landing page…either the default tab (for the Tab container) or the Site.com default page (for the Site.com container). By inserting your own Visualforce page into this setting, you interrupt that redirect and take full control over the user experience.

Hybrid Containers

The three container choices outlined above are not mutually exclusive. When using the Communities Container, it’s still possible to use Visualforce and Site.com to drive portions of the community. When using the Site.com container, it’s possible to use standard pages and Site.com-driven pages to manage portions of the community. When using Visualforce, it’s still possible to use standard pages and Site.com-driven pages. And since this is the web, linking across the various containers is always an option.

Knowing Your Options

The choice of a primary container in a community has implications as you build that community. While this article is not intended to be an exhaustive list of those implications, we’ll attempt to bring some clarity on the implications of choosing a container. We’ve broken out our implications into several categories for each container:

  • Page Construction

  • Branding Approaches

  • Navigation Paradigm

  • Mobile Strategies

  • Declarative Build Tools

  • Programmatic Build Tools

Think of this guide as rough notes to get your thinking started. The choice of a community container is ultimately up to you. And knowing your options is a key element of success.

Communities (Tab) Container:

Page Construction:

Standard Layouts (Chatter Tab, etc)

Customized Layouts (Records)

Visualforce-Driven Layouts

Site.com-Driven Layouts

Branding Approaches:

Static HTML Files, CSS Tweaks

Limited branding control with static files.

Navigation Paradigm:

Salesforce Tabs, Configured in Community Setup

Mobile Strategies:

Salesforce1 (Spring ‘14)

Responsive Sites with Visualforce or Site.com

Declarative Build Tools:

Page Layout Editor


Programmatic Build Tools:


The tab container is often the fastest path to standing up a community. The ability to reuse standard layouts, while retaining the full flexibility of both Visualforce and Site.com to drive some pages keeps this container in the realm of the familiar for much of the Salesforce ecosystem. But that comes at the expense of flexibility, as the traditional Salesforce tab paradigm imposes a horizontal navigation structure, and is not currently built on responsive design principles. It’s possible to overcome some of this with Visualforce and strategic redirects from the active site homepage, or via Salesforce1 browser edition, but those looking for full markup flexibility will want to also evaluate the Visualforce and Site.com containers…either as a replacement or for use inconjunction with a tab-driven community.

Site.com Container:

Page Construction:

Site.com Studio – Templates, Pages, Widgets

When Site.com drives your community, you cannot use standard layouts and must construct those layouts in Site.com.

Branding Approaches:


Full branding control with Site.com.

Navigation Paradigm:

Site.com-driven navigation

Site.com mas menu navigation to community pages, as well as the ability to add navigation driven by data in your salesforce org.

Mobile Strategies:

Responsive Design in Site.com

Integrate your favorite responsive framework (Bootstrap, etc).

Declarative Build Tools:


Force.com Objects

Programmatic Build Tools:

Javascript in Site.com Widgets

Site.com does not currently have a server-side programming language. But Site.com widgets can consume REST web services written in Apex.

Site.com offers unprecedented layout flexibility, great templating, and content & pages driven by business users. When used to drive a community, pixel-perfect is within the realm of possibility…and business users can keep the community content fresh, all while easily conforming to corporate branding & layout guidelines embodies in Site.com templates. Data stored in Salesforce can be easily exposed on pages using repeaters, and leads & other data can be easily captured using Site.com’s forms capability. But driving a community or a page through a declarative web content management system can be a bit foreign to developers, who are used to the power and flexibility that code-level control of a page can bring. As of Spring ‘14, anyone looking to create a responsive community primarily focused on service & support or presentation & collection of data should consider the Site.com container.

Visualforce Container:

Page Construction:


 NOTE: Third party CMS tools like Orchestra CMS can be used to build pages in this container as well.

Branding Approaches:

Visualforce + Static Resources

Navigation Paradigm:


Mobile Strategies:

Responsive Design

Salesforce1 (browser)

Declarative Build Tools:

Limited: Custom Objects & Field Sets

Note: some standalone pages could be driven by Site.com in this model.

Programmatic Build Tools:



Javascript & REST

Visualforce provides a great deal of flexibility and control when constructing a community, and provides many prebuilt components that can make a developer more productive. This flexibility can come at the expense of organizational agility, as most changes to a community must go through a team of developers, as opposed to administrators or business users. But for heavily interactive communities with application-style functionality, Visualforce seems a good option.

The practice of designing a community is an evolving one. And the art of choosing a community architecture is evolving as well. The input of the Force.com community will be critical to this process. As you build your understanding of these containers, as you deploy and learn, please chime in! We’re compiling these discussions under the #Communities Containers topic in the Salesforce Success Community. Your comments and insight are needed!

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS