Backing Up Your Data

Salesforce is so reliable and available, it is easy to forget to back up your data locally. Lately, I’ve was reminded that it is a good idea to back up your Salesforce data from time to time. Salesforce allows administrators to download a complete export up to once a week.

It isn’t that you have to fear for the Salesforce database crashing or being lost. I recommend downloading for a couple reasons:

  • It could help if you ever accidentally make unintended changes to data and want to return to an earlier state.
  • It could also be helpful in the event that Salesforce or your internet access ever goes “down” at a critical time – you’d have a way to access your data offline.

To download the backup, go to Setup (Administration) | Data Management | Data Export. Click the button – a while later you’ll get an email with a link to download your data file. Save it somewhere safe.

Alternatively, if you use Demand Tools, you can back up to a file as often as you like. I use this to create a copy of the database in a Microsoft Access file.

Links to Resources from the NTC Presentation

Since the links in our PowerPoint slide didn’t make it through to Scribd, I thought I’d add them all here so they’re in one place.

The OPML File is here:

http://www.nonprofitcrm.org/attach/google-reader-subscriptions.xml

To use this, you’ll need to right click (option-click on a Mac), and save this file. To import this file in Google reader, instructions are here:

http://www.google.com/support/reader/bin/answer.py?hl=en&answer=69982

To import in Bloglines, instructions are here:

http://www.bloglines.com/help/faq#import

NTC Session Presentation- Using Salesforce.com for Good not Evil

Below is the slide show from our session at the Nonprofit Technology Conference (or click this link: http://tinyurl.com/2578gp):

Read this doc on Scribd: NTC Salesforce for Good

Microsoft Dynamics CRM - A first look

I recently spent some time learning more about Microsoft Dynamics CRM and I must admit the product looks very interesting! For those of you that are more familiar with Salesforce.Com, I will try and draw out some of the similarities and some of the differences. I haven’t had a chance to do a nonprofit implementation with Dynamics CRM, so this is very much just a first look based on information I have read and some online demos.

The first major difference between the two platforms is how they can be run. Salesforce is locked in to the On-Demand model. Microsoft offers the ability to run Dynamics CRM either as an Internal Application or as an On-Demand offering through their CRM Live service. At first glance, it appears as though Dynamics CRM would be more feature rich when run as an internal server based application. It derives its value from making the assumption that end users are most familiar with MS Office Suite of Products. It has very tight integration with MS Outlook and MS Excel. Below is a screenshot of how CRM Dynamics looks in a familiar MS Outlook Environment:
Read the rest of this entry »

Web to lead: requiring fields with Javascript validation

In a previous post, I talked about a few ways that I customize web-to-lead forms. One key change I make is to ensure that certain fields get filled in for every web lead. In a Salesforce page layout, you can require fields, but web-to-lead doesn’t allow you to do this - any web-to-lead form submission will create a lead, even if critical fields such as last name or email are left blank.

Most of our clients want to make sure their leads fill in a minimum amount of information, such as name and email. Moreover, you can catch spam by requiring sensible entries - since spammers don’t always fill in the fields.

Read the rest of this entry »

It’s all about your process!

I’m going to take a step back from all the technology talk to discuss process.  How you do what you do, whether it’s fundraising, member management, or email blasts, is equally as important as what technology you use to do it.  When you’re implementing a new system, whether it’s Salesforce, eTapestry, Constant Contact, etc., it’s a great opportunity to review how you’re doing these things, and, more importantly, make changes to improve.

I recommend using some kind of process mapping tool (Microsoft Visio on the PC side, Omnigraffle on the Mac side) to help you visualize how to do this kind of stuff.  I like creating Flow Charts (people have usually seen these before) with Swim Lanes because people seem to intuitively "get" those more than other types of Business Process Modeling diagrams. It’s important to get all the process owners in a room and talk through how things go. 

In one instance, it turned out that the Membership team categorized the same person differently than the Program team, and they were using different terminology, even though the relationship to the organization was the same!  Imagine how confusing this can be when you’re talking about 4 or 5 processes that you’re trying to map to another system.

Another benefit to walking through (and mapping) these processes is that lots of "hidden data" tends to appear, sometimes to the surprise of other people on the same team!  Another war story: someone in Fundraising had been recording all donations in a private Excel spreadsheet, even though there was an existing custom Access database supposedly designed to track donations!  When asked for information about donations, no one could get the right info from the database, so they would always go back to the Fundraising person who magically had the right info.  Once everyone found out the "secret", there was a collective sigh of relief, and then they were able to work on fixing their broken system.

Here’s a sample process map to take a look at:

 

 

NPSF Roundup - March 14

For the past month, I’ve been collecting random tidbits to share via this blog. Multiple projects in full force tend to keep tripping up my best intentions. My fellow nonprofitcrm bloggers Evan and Anand - who are both far busier then me - have essentially shamed me into getting my act together. My intent is to do a weekly monthly roundup of salesforce.com news relevant to nonprofit practitioners and users. An aside: I’ll continue to add interesting articles I come across to the Google Notebook above if you want to subscribe to the RSS feed.

NTC

The big news coming up this week for NPSFers is NTEN’s Nonprofit Technology Conference in New Orleans March 19-21. As usual there are several Salesforce happenings at the conference:

Please come find me, email me, Twitter me, whateves - I’m always looking for a good sf.com geek out.

NPSF Group

There’s been some raucous discussions on the NPSF Google Group this past week on the direction of the NP Template and a benchmark sf.com data model for nonprofits in general. In my opinion, this discussion is a long time coming and is essential for the long term sustainability of nonprofits using sf.com. On the next NPSF conference call on March 27, we will begin to hammer out issues.

Bloggers and Developers

Buzz

There’s been all sorts of buzz about sf.com being bought out by Oracle or even Microsoft (I have to admit, this scares me a bit when thinking about the sf.com Foundation’s donation to nonprofits). There was even some speculation about CEO Marc Benioff looking to buy Zoho because of of the competitive threat they pose (if you’ve ever seen the Zoho CRM offering, its an amazing rip off of sf.com). Techcrunch went further to wonder if Zoho’s new HR product People upped the ante in threatening sf.com dominance of the business SaaS market.

Google Apps Integration

Well perhaps this is sf.com’s answer. Steve noticed a couple weeks ago some interesting new things popping up in sf.com that suggested integration with Google Apps may be on its way (I saw this too and thought one of my co-workers had added a new app at first). It looks like there is proof on the Google App side that integration is on its way: http://tinyurl.com/2269zz

Fundraising

As always, Steve Andersen is kicking ass developing killer functions in sf.com. Checkout his latest Jing Screencast of how he’s using Apex to roll-up donation summary info onto the Contact and a formula field to qualify their donor level based on their giving history. Kudos my friend.

Reporting and Dashboards

The sf.com Reporting and Dashboard Blog is invaluable. R&Ds can be trying components of sf.com, but these guys really help understand what’s possible (and more importantly, what’s not).

Sf.com goes all mobile

For both Blackberries and iPhones

To Integrate Or Not To Integrate?

Almost every time we encounter an organization with multiple applications running their operations, we always hear the same request for a fully integrated real time data solution with a CRM solution acting as the glue holding everything together. While this is technically possible, we rarely end up delivering this type of solution after going through a cost-benefit analysis with the organization. Below is some of what we consider and cover in that decision making process:

Step 1: Determine the Value Proposition of Integration

The first and most important consideration is to determine the real value that this integration will bring to your organization. In most cases we find that organizations are already generating integrated views of information even if they come from separate applications. This is often done with some manual analysis using Excel and other tools. The real value of a systems integration project can be measured in the following ways:

  • Costs Savings – How much are you saving in labor costs by not making your employees do the extensive manual analysis to reconcile data from multiple applications?
  • Time Savings – What benefit does having this data in real-time or near real-time provide to your organization?
  • Accuracy – Does systems integration result in more accurate reporting? If so, how much in savings are you achieving through better information.

Step 2: Evaluate the Integration Approach Alternatives

Generally speaking there are three integration approaches we often discuss with organizations.

  • Manual Integration – Allows you to synchronize data back and forth between systems, however, it is driven by a manual process. This is typically done on a weekly, bi-weekly, or monthly basis often with several tedious steps.
  • Uni-Directional Integration – In this situation, we make a determination that one Application will be the primary and another one will be the secondary. The Primary application always sends data to the secondary application(s), however, it never receives any data back. Uni-directional integration can either be real-time or conducted in batches (such as nightly updates).
  • Bi-Directional Integration – This is the most complex type of integration and also the most often requested. In this situation applications transact data (often in real-time) in both directions. For this to work effectively rules must be in place to resolve conflicts. A conflict is a situation in which both applications attempt to update the same information at roughly the same time. In this situation, we need to be able to establish an order of precedence as well as a transaction log so we can correct any mistakes.

Step 3:  Perform an ROI Analysis of the Alternatives

For each of the integration alternatives consider the Return on Investment (ROI). While you can consider an investment over a longer time horizon most IT investments are often evaluated on a 3 to 5 year time horizon.

 

 

 

The above chart is meant to be a hypothetical analysis of cost/benefit and ROI for an organization. Actual costs will depend on the complexity of your existing applications and the integration solutions you decide to go with. The above chart is also not meant to be an endorsement of Manual Integration. For many organizations this might be the right approach, however, that determination can only be made after a careful analysis of your integration options and your internal cost structures.  

Web to lead: Javascript phone formatting

In a previous post, I talked about a few ways that I customize web-to-lead forms. One of the most important improvements you can make, I think, is to add Javascript functions to format phone numbers.

When you enter 10 digits into a phone number field in Salesforce, it gets formatted as (206) 555-1212. Web to lead forms don’t do this by default, so phone numbers show up in Salesforce with inconsistent formatting. This is the reason I first started fiddling with Javascript in web-to-lead forms.

Javascript lets you change data when a website user moves out of a field - you simply respond to the onblur event by calling a function such as my formatPhone function. In the web to lead form, your phone field tag will look like this:

<input  id="phone" maxlength="40" name="phone" size="20" type="text"
     onblur="formatPhone(this);" />

The Javascript code goes in a <script> block within the <head> section of the web page:

<script language="JavaScript" type="text/JavaScript">
<!--
    //Written by Evan Callahan, NPower Seattle
    function formatPhone(num) {
    var re= /\D/;
    var newNum=num.value;
     if (newNum != "") {
        while (re.test(newNum)) {
         newNum = newNum.replace(re,"");
        }
        if (newNum.length == 7){
           newNum = '(206) ' + newNum.substring(0,3) + '-' +
               newNum.substring(3,7);
           num.value = newNum;
        }
        if (newNum.length == 10){
           newNum = '(' + newNum.substring(0,3) + ') ' +
               newNum.substring(3,6) + '-' +
               newNum.substring(6,10);
           num.value = newNum;
        }
      }
    }
//-->
</script>

My function defaults 7 digit numbers to a 206 area code - if you aren’t fortunate enough to live in Seattle, you can replace this with a different default (or skip the whole section).

Ideas for better Web to Lead forms

We use web-to-lead forms pretty extensively for our Salesforce clients, because it is so much less expensive for them than integrating with the API.  We’ve found that WTL can work not just for ordinary leads, but also for simple event registration, volunteer signup, pledges, and many types of "applications" for service or grants.  Leads don’t have to be just people - they can bring in organization, donation, grant, or service information as well.

For example, we worked with a group that matches teen interns to other nonprofits that need interns.  The organizations that want interns apply for services on a web-to-lead form; the teen applicants sign up on another.  The first type of lead gets converted into an account, a contacts, and an internship "opportunity," while the intern applicants stay as leads until they are either matched to an internship (via contact roles) or rejected and deleted.

This is just one example of how web-to-lead has allowed us to set up simple website integration relatively quickly.

The more you use web-to-lead, however, the less you’ll like the HTML form that Salesforce provides you.  We edit the form pretty extensively, for several reasons:

  • To arrange and align form fields in a table and apply styles
  • To format phone numbers and other values as they are entered
  • To provide validation, making certain fields required and helping to avoid spam
  • To set hidden values, such as Lead Source or Record Type, that we don’t want to show on the form
  • To create or modify a picklist for values, such as Campaign

The first thing I do for web to lead is format the form in a table - two columns, with the labels at left and the fields at right. Then I add styles for labels and fields to the stylesheet.  For examples, take a look at forms for Teens in Public Service, Communities Connect Network, and Arts Corps.  To see the form’s HTML, view the source code for the page and search for WebToLead.

I will offer other a few other examples of web-to-lead techniques in subsequent posts.