Prelude Interactive

From October 2008 to February 2009, Prelude Interactive built the first phase of the Points of Light Institute’s ambitious reporting and data collection system. The POLI supports more than 250 affiliate organizations around the United States and elsewhere. To encourage full affiliate participation, the POLI wanted to provide immediate feedback and accessible reports – rather than risk the affiliates feeling that their painstakingly collected data was disappearing into a black hole.

Major Requirements

1. Use SalesForce.com infrastructure, including the Customer Portal, Apex, and VisualForce.
2. Build a survey tool capable of collecting up to 450 pieces of information, while not overwhelming the person filling out the survey.
3. Build ’skip logic’ into the survey, to hide non-relevant questions based on previous inputs.
4. Generate several re-usable reports from survey data, available without delay after survey completion. Two reports directly address the data of individual affiliates, while a third report provides aggregate data for the entire network.
5. Build flexible graph, chart, and data table functions to facilitate attractive data display in the reports.
6. Use the Customer Portal to provide survey and reporting access for affiliate members.

Implementation

The client and Prelude initially considered using an off the shelf survey application, either from the AppExchange or as a non-SalesForce component that would exist in POLI’s public web site. However, these components either required significant data setup in SalesForce, or stored the data in a manner which was too opaque or abstract for most users who would later need to run reports and analyze the data.

Early on in the project, POLI decided to implement SalesForce’s Customer Portal for their affiliate users. While it caused the rollout to be slightly more complicated, launching the survey within the Customer Portal was an excellent way to introduce SalesForce and the Customer Portal to their users.

With the advent of POLI’s Customer Portal, and wanting the full customizing power of SalesForce.com, Prelude and POLI agreed to implement the survey data as a single Custom Object, and to build the survey itself in VisualForce and Apex.

Technical Road Blocks

• We discovered a practical limit to the size of SalesForce custom objects. We knew that loading 450 fields onto a SalesForce custom object was not commonly done, and that we would probably run into some issues. When instantiating a custom object, SalesForce runs a query to retrieve the value of each field used in a VisualForce page. Rather than running “SELECT * FROM object”, the query is constructed as “SELECT field1, field2, field3….FROM object.” This long query ran up against the 10,000 character limit on SOQL queries and we were forced to construct a second custom object with a Master-Detail relationship to the primary survey object.

• Ajax-like functionality is supported in VisualForce with tags such as actionStatus and actionSupport, along with arguments like ‘rendered’, ’styleClass’, or ’style’ for controlling UI functionality. We found these tags, and the underlying functionality, to be far less responsive or versatile than using a Javascript framework such as jQuery or Mootools.

• We could not find a Custom Object mechanism which would allow us to run validation rules on an object, report errors, but still save the data. Thus, we built validation methods using Apex rather than using validation rules.

Lessons

Our experience with the project reaffirmed our belief that skilled, experienced administrators at the client are valuable, if not crucial. POLI is extremely fortunate to have several dedicated individuals who were an immense help in completing this project. We also continue to believe that organizations who are unwilling to hire or train dedicated administrators of their enterprise software are doomed to spend far more money on consultants than they would have spent retaining these valuable employees.

SalesForce.com is a very powerful system for building business applications. While VisualForce is a helpful extension of this power into UI building, we found that for well designed, dynamic UIs, a non-SalesForce tool such as jQuery or MooTools, combined with clean CSS, does a better job with fewer frustrations. We also identified several bugs with VisualForce and Apex and were sometimes forced to go to great lengths to code around them.

We also learned that skilled, competitively priced SalesForce.com contractors are rare. ‘Real programmers’ tend to shun Apex and VisualForce as they are proprietary languages too closely tied to a single platform. ‘Real SalesForce administrators’ tend not to have the technical experience to make full use of Apex and VisualForce. We missed several intended deliverable dates because we were unable to find the right kind of talent in a timely fashion. Because SalesForce is such a unique skill, competent contractors often charge hourly rates which aren’t sustainable when working with nonprofit projects.

Stay tuned for our update from Phase II!