gokubi.com

I want to show you a quick and easy way to take live data from Salesforce.com and post it on your website using Salesforce Sites. You can see lots of hard-core examples of how to use sites. Those are cool, absolutely no doubt. People are building amazing things.

There also are opportunities for very targeted uses of Sites. With these micro-sites, the investment-to-value ratio can be really high. Here’s an example of one such use case.

The Use Case

A nonprofit wants to have a page on it’s website acknowledging all sponsors who supported events in 2007. They want a simple list of organizations, leaving out any who have asked not to be thanked publicly.

The Data

Sponsorships are tracked as Opportunities connected to the relevant Account. Here’s the Opportunity related list from the relevant Account:

I have created a rollup summary field on the Account to sum up all Opportunities from 2007:

And I’ve created a checkbox to flag Accounts that want to stay anonymous. You can see both fields on the account detail page:

The Display

I want to show a simple list of donors that gave in 2007 and aren’t anonymous. To do this, I need to create a VisualForce page with a simple Apex controller so I can grab the right data, and then display it correctly

Here’s the Apex controller where I’m grabbing the data that I want. You can see from my SOQL statement that I’m only getting Accounts where the rollup field is greater than zero and the anonymous field isn’t checked. I’ve named it donorListing:

public with sharing class donorListing {
	List<Account> accounts;
	public List<Account> getAccounts(){
		accounts = [select name from account WHERE X2007_Giving_Total__c > 0 AND Anonymous_Sponsor__C = false ORDER BY Name];
		return accounts;
	}
}

Here’s the VF Page where I display the data. I point to the Apex I created via the controller attribute of the page. I also turn off the Header, so that I don’t see all the Salesforce navigation elements. Then I just list out the sponsors.

<apex:page controller="donorListing" showHeader="false">
	<apex:dataList value="{!accounts}" var="account" id="theList">
		<apex:outputText value="{!account.name}"/>
	</apex:dataList>
</apex:page>

And here is what the VF page looks like in my browser when I’m logged in to Salesforce.com:

OK, looks great. But I want it visible to people not logged into Salesforce. To do that, I need to create a Salesforce Site.

The Site

You can create a Salesforce site at Setup | Develop | Sites. Create a site, and give it a name. It will show you the URL for this site. That’s the URL people can hit from anywhere on the web to see your VisualForce pages.

You associate VisualForce pages with a Site on the Site detail page. You’ll see here my donorlist page is a part of this site:

Next, I want to make this page visible to the public–I don’t need people to login to see it. That’s done by modifying the public access settings:

Make sure your pages and classes(classes used by VisualForce pages are added automatically) are associated with the site:

OK, now we’re ready to hit the page at it’s external location. For this example, the URL is:

http://smsdev-developer-edition.na6.force.com/sms/donorlisting

The end product

Now that we can see the page publicly, we can embed it anywhere on the web using something called IFRAME. It’s a part of the HTML that runs the web, and has been around for a long time. Here’s the code for embedding this page in my website:

<iframe src="http://smsdev-developer-edition.na6.force.com/sms/donorlisting" width="100%" height="150" frameborder=0>

The nonprofit can now paste that IFRAME code into it’s website content management system. I’ve done just that in this post–you can see the sites page embedded right here:

When you hit this page, you’ll see the live data. If I get new sponsors or I flag sponsors as anonymous, they’ll appear or disappear accordingly. Just manage your data through your normal process and the public acknowledgement just happens.

Heck, you could even put workflow on the Account that automatically sends an email to the Account when they make this list. That email could contain a link to the acknowledgement page. That’s a pretty nice thank you experience for the sponsor, I think.

The challenge

This is a very simple example meant to get you thinking about what’s possible. What do you want to do with Sites? Come up with your own use cases and implement them in a developer org. As you can see, there isn’t much code involved to get it working. Show your boss what’s possible with an example. Tell them how long it took you to get data shared on your organization’s website. Modify the data in Salesforce.com and then hit refresh in the browser. Astound and amaze! And then build Sites into your business process for quick and easy publishing of your Salesforce.com data.

John Kucera is posting an awesome series about doing complex engagement work with Campaigns and the new enhancements in Summer ‘09. This is killer stuff John!

I just posted over on the Salesforce.com Nonprofit blog that we are releasing the Nonprofit Starter Pack as an open source project!

The post tells the full story and provides links to all the relevant resources: project site, issue tracker, code base, and documentation.

Come join us in this effort!

I inherited a code base when I started at the Salesforce.com Foundation. If you’re a Salesforce.com Admin or consultant, you may find yourself in the same position. What’s the best way to come up to speed on a new code base? It can be a daunting process.

In one of my last projects at ONE/Northwest I started working on a very complex Salesforce implementation someone else built. There wasn’t any Apex or VisualForce, but the config was really gnarly. Getting my head around the record types, custom objects, and fields was a real bear. I saw some things I don’t like to talk about…

With my new job, the config isn’t particularly complex. There are relatively few objects and no record types. But there is Apex and some VisualForce. Here are the steps I’m undergoing to get my head around the code:

Put out any fires

• Make sure the code is under source control.
• Deal with any mission critical bugs, but remember you don’t really know what’s going on yet.
• Set up an issue tracker and get it ready to collect issues you discover in this process

Schedule a demo so that you have a short-term goal

• I was asked to demo the NPSP for the Boston user group only a week after I started. I said yes because I knew it would force me to get comfortable with it.
• If you can’t demo to real users, demo to someone who will ask tough questions and understands the business process well enough to make you sweat.
• If you can, build out your own demo org rather than using one that’s already built. You’re code may not be packaged, so this might not work for you.

Understand the application flow

• Read any user documentation you’ve got
• Talk to anyone available who was involved in the design so you can try to understand the intent of the application flow.
• Click through the UI to see what happens
  • Take the time to document the application flow in a flowcharting program, like Visio or Omnigraffle–writing it down forces you to fill in the blanks
• Discover all the button overrides
  • Find out where cool stuff is happening with Triggers and where it’s happening with a VisualForce page

Dig into the code and see how that application flow is accomplished

• Look at existing Workflow to see what processes are handled there
• Look at the code
  • Start with triggers, this is where the action happens
  • Take notes – update the application flow diagram with markers where Triggers fire
  • Look at the existing tests for nods toward key behaviors
• Go back to workflow
  • If your workflow is complex, write detailed tests to prove the functionality
  • Just because you can write Workflow by pointing and clicking doesn’t mean it will be easy to understand the behavior without testing

Document what you now know by heart

• Someone will be inheriting this code from you, so think about what you just went through and be kind.

For me it feel like probing in the dark with little parts of the picture slowly becoming illuminated. Follow your instincts about what to dig into, but don’t go to ground in any one area until you have a shallow understanding of the whole thing. Probe into the darkest corners until there is enough light to know how scary it is, and then move on, shooting for the whole room to reach dusk, and eventually, bright light.

I think it’s fun, this process of discovery. It’s much more fun when the code you are inheriting is well-designed, like this code is. When it’s rationally designed, your life is much easier. You’ll still have lots of work to do, but it won’t feel like a giant tangle of yarn for very long.