The Power of Force.com Sites

Michael McLaughlin

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 <apex:page> 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.


• Beg, borrow, and steal from your current webmaster all of his/her stylesheets, javascript, and images so your Sites pages are seamless from any static pages.


• 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!

TinyURL POST API

I was exploring Twitter's use of the TinyURL utility and couldn't find any more information on their API from their website. After a small amount of Google searching I found the HTTP POST API for TinyURL.

So, a small example:

http://tinyurl.com/api-create.php?url=http://www.appirio.com/techblog

Returns the plain text:

http://tinyurl.com/7vzap5

Have fun.

Using Workflow to Update a Case When an Email-to-Case Message is Received

Andrea Giometti

We are going back to basics here, but recently we were looking to implement what seemed to be basic functionality and found ourselves jumping to complex solutions while overlooking the native functionality within Salesforce.  With the development tools now available in Salesforce such as Visualforce and Apex Code, customizations are seemingly limitless.  However, why reinvent the wheel if a solution already exists within Salesforce's standard functionality? 

The issue was that we needed to update the status of a case in Salesforce when an inbound email was received for an existing case via email-to-case.  It turns out that since the Spring '08 release, you can do this with standard email-to-case workflow.  When you enable email-to-case in your org, an object called Email Message is enabled for workflow rules. In that object is a field called 'Is Incoming' which is set to true for any inbound emails.  The key to the workflow is that you don't apply it to the Case object, you apply it to the Email Message object.  This will allow you to then do a field update on the Case object.  Similarly, you can use workflow rules when a case comment is received by applying the workflow rule to the Case Comment object.  This can be particularly helpful if you are using a Customer Portal and want to update a field on the Case object when a customer adds a comment to a case.

By implementing a simple workflow rule, we were able to add functionality that would automatically re-open a case if an email associated with a closed case is sent by the customer.   Others uses for this workflow rule could be to re-assign a case, say to a queue, when an email is received and the case meets certain criteria.  In addition to checking the Is Incoming field, you could also create a workflow rule that checks the status of the email message and makes changes to a case field based on that status.  Basically, once you discover the Email Message object is available in workflow, the possibilities are endless.

To create the workflow rule that updates a case field on an inbound email:

1. Go to Setup | App Setup | Create | Workflow & Approvals | Workflow Rules and click New Rule.  
2. Select Email Message as the Object the workflow rule applies to and click Next (note that Email Message will only be available if email-to-case has been enabled in the org). 
3. Enter a name for the workflow rule and select when it should be evaluated.
4. Enter the following criteria to enable the workflow rule to fire when an email is inbound:
   • 'Email Message: Is Incoming' equals 'True'
5. Add additional criteria if you only want the workflow rule evaluated under certain circumstances such as Case: Closed equals True, or Case: Status does not contain Closed.
6. Click Save & Next
7. Click Add Workflow Action and select New Field Update
8. Enter a name for the Field Update and then select the case field to update.