The announcement at Dreamforce 2008 of Force.com Sites was huge. Yes, it does allow organizations with minimal IT staff to consolidate their Salesforce.com instance along with their public-facing web presence (see the Cathedral Partners Sites-based public web).
But even cooler than that, it allows that same public-facing web presence to show content directly out of your Salesforce org! Of course, you could just pull “content” out of your org, but the power of Sites is being able to pull real-time data…without authenticating! Enough with the marketing pitch…what does that mean to you? The ability to read and write data in your org as a public user is huge. For example, you can present real-time dashboard-type data about the number of accounts you are servicing, an up-to-date product and pricing list, hot news items, or the latest campaign details. This kind of data would typically need to be extracted from Salesforce, digested, and reposted to your external site…a process that, including reviews and upload cycles, could take days or more. Now it’s all instant!
OK, so Sites is a great tool. Here are some gotchas and areas to double check before publish your Sites site:
- Ensure that you are not showing too much data
- —The ability to show real-time production data is a huge benefit, but it is also a huge liability. Ensure that the Public Sites User is locked down and only has access to the objects you want to publish.
- Be sure all the correct switches are flipped
- —Nothing is more frustrating than going live with a dud site! The public setting on your controllers, images, and static resources needs to be True. The Cache and Expires parameters on your
tag need to be appropriately set so users avoid stale data. Hint: the Expires parameter is in seconds. Set it appropriately. These parameters might seem useless (after all, why not always pull the latest data?) but they can be cost savers since Sites is priced on number of page views. If you can prevent users from costing you a page view every time they hit their back buttons, I’m sure your CFO would appreciate it!
- Sites is built on standard Visualforce pages with Apex controllers. This means that test methods and coverage limits must be met before deploying.
- Furthermore, ensure that you have pointed your Sites URL at your domain. For example, out of the box, your Sites URL will be something like yournamehere.na1.force.com. To present a truly seamless look and feel (in case your users glance up at the URL), work with Salesforce and your web host to have the CNAME record point at your “friendly” URL.
- Finally, polish up your error pages. When you enable Sites, you get several standard error pages for such typical errors as a 404 (page not found) and 501 (server error). Be sure to apply the same stylings to these pages as you did to the rest of your Sites implementation to make it look super-slick even when a user hits a boo-boo.
Sites isn’t generally available for all orgs at the time of this writing. Be sure to hit this link to ask for Sites in your org. The general guesstimate for availability is summer 2009. Have fun and be safe!