Record Types and Page Layouts
The main part of today's meeting focused on record types and page layouts. It's hard to summarize what we covered in a blog post, but I'll give it a quick try.

Record types are a way to categorize the records in a given object -- e.g. for your Organizations (aka Accounts for those of you not on the Nonprofit Template) you might have record types of Business, Foundation, Government Agency, and Nonprofit. Having these record types then lets you do a couple of powerful things. First, you can use the record type in any kind of reporting that you do to see results according to the kinds of entities that matter to you. Second, you can assign a different page layout to a given record type. So, for example, if you have one record type of School and another of Business, you could have corresponding page layouts. Then, on the School layout you might display a related list of teachers and classrooms, and display and hide certain fields. For example, you could display the field for school mascot on the School layout and hide it on the Business layout.

We also covered page layouts and looked at how you can easily drag and drop fields onto and off of the layout. You can also add/remove sections and related lists, set some field-level properties (read-only and required), and choose whether to have one-column or two-column displays.

Minh said that she's found that if you're going to assign a record type to a page layout that doesn't yet exist that it's better to create the page layout first and then create the new record type.

Charles said that he uses a related list to further expand the types of nonprofit organizations. This means that when the record type is set to "nonprofit" that a dependent field is made active, allowing the user to specify what kind of nonprofit it is with an additional picklist.

Charles said that he finds the Console to be a great way to have relevant information about the contact, organization, and donation all displayed on one screen.

Reporting
We also talked about reporting in Salesforce. There isn't quite as much that I can say in this blog post. It's pretty easy to go to the Reports tab and to work your way through the wizard. One tip that Michael  (?) shared is that you should avoid setting date-based criteria in the standard filters, it's much better to tell your users to delete the date criteria in the standard filters and to use the advanced filters (below on the same screen) for any kind of date-based reporting.

Charles said that he wishes there was a way to report on leads and contacts in a single report. The only way he's found around this is to query on the subject field of mass e-mails that were sent, which will pull up both leads and contacts. If anyone knows a better workaround please post a comment on this blog entry.

Spring 08 Release
The Spring 08 release will be available very shortly. One highlight is "Outer Joins." What does this mean? It's a way to view certain records whether or not other records are present. It's easier to illustrate this with an example. You could do an outer join to find all organizations (aka Accounts), regardless of whether there are any contacts at that organization. This would then allow you to do things like seeing what percentage of your organizations you do have contacts for. This concept can be extended to other objects in Salesforce, including donations (aka Opportunities), Cases, etc.

There is a succinct overview of Outer Joins on the Salesforce blog. And a more in-depth discussion of how you can use Outer Joins by Thomas Tobin. Please note that Outer Joins are not the same thing as exception reporting. (Exception reporting is where something is not expected or not normal. For example, finding all Contacts that do not have donations.) However, there are some workarounds for creating exception reports, even though it's not built in to Salesforce.

Here's the full list of Spring 08 features.

Avoiding Spam Leads
Charles mentioned that he has been getting spam leads submitted on his website (with Salesforce Web-to-Lead forms). One way to get around this is a solution that Scott Hemmeter came up with. It uses some PHP scripts to intercept the data that is submitted before it goes into Salesforce as a new lead. The scripts send the data off to Akismet to score it for its spaminess. The data then gets submitted as a new lead with a custom checkbox field for indicating whether Akismet considers it spam. (Akismet is a technology for blocking comment spam on blogs.) This is not trivially easy to implement, but Scott does give fairly detailed instructions. To implement this you should know what PHP is and have a website using PHP -- such as Drupal or Joomla. I've also seen a company that offers this as a paid service, but it cost about $100/month. Check out more details about this anti-spam-lead solution on Scott's corporate website.

Moving Beyond Web-to-Leads to "Web-to-Anything"
Minh asked whether data submitted by website users could post to objects other than the Lead object. (In other words, if a teacher filled out an application on your website, could their personal information post to a Lead or Contact record, but could the information about the school post to a related Account record?) The answer is that Salesforce can't do this itself. However, Clicktools makes this possible. This used to be completely free for nonprofits, but with the recent change in AppExchange pricing, Clicktools had to begin charging for this software. Clicktools also lets you send out e-mails to leads and contacts that solicits them to update or fill in information on their record and the data is posted back to Salesforce. I've never used it, I don't get a kickback (!), but I've heard great things about this product.