gokubi.com

I can’t stop giggling. My first 25-line Apex coding project will replace a 400+ line S-Control. Seriously, it’s blowing my mind a bit.

Here’s the code:

trigger HouseholdCheck on Contact bulk (before insert) {
  for (Contact c : Trigger.new) {
    if (c.ONEN_Household__c == NULL) {
      String RecognitionName;
      RecognitionName = c.firstname + ' ' + c.lastname;
      ONEN_Household__c hh = new ONEN_Household__c (
        Name=RecognitionName + ' Household',
        Recognition_Name__c=RecognitionName,
        Recognition_Name_Short__c=c.firstname,
        MailingStreet__c=c.MailingStreet,
        MailingCity__c=c.MailingCity,
        MailingState__c=c.MailingState,
        MailingPostalCode__c=c.MailingPostalCode,
        MailingCountry__c=c.MailingCountry
      );
      insert hh;
      c.ONEN_Household__c = hh.id;
     }
     if (c.AccountId == NULL) {
       Account[] account = [select id from account where Name = 'Individual'];
       c.AccountId = account[0].Id;
     }
  }
}

I won’t paste in the 400 line HTML form and code that it’s replacing…

All the new code does is create a Household for a Contact when you’re creating a Contact. If you’ve selected a Household, it doesn’t create one. It also adds the Contact to the Individual account if you haven’t picked a different one.

Simple, huh?

But it’s been really hard to do in Salesforce.com before Apex. We had to build a custom Contact creation form that was seriously 400+ lines long.

Not only does it replace my custom data entry screen, it fixes all sorts of problems. We couldn’t use Quick Create because a Household wouldn’t be created when the Contact was–now it will. We couldn’t let people sync Outlook contacts for the same reason–now we can. When a Contact is created anywhere, anyway, by anyone, the trigger will fire, and they will have a Household.

That also makes the integration story better. Our Plone integration won’t have to care about the Individual Account. It won’t have to worry about Households. We’ll have an Apex trigger like this one that will take care of our crazy business rules behind the scenes.

I knew Apex was coming and that it would make this kind of thing possible. But actually learning enough of the language to write this code in under two hours was more than I could have hoped for.

Apex is revolutionary. These guys are definitely on to something.

Ismael wrote a post about how all Office 2.0 startups should join the Appexchange as a way to raise visibility and drive business. So, I’d like to give him and Zoho.com an idea for a nice Appexchange product that would be really easy for them to write.

I like the Salesforce.com Word integration that lets you create one-off mail merges from records in Salesforce.com. It makes thank you letters, and other non-batch documents easy to knock out.

It only works in Windows with MS Word, however. I’d like to be able to do one-off mail merges on any platform. So why not do it with Zoho.com?

Zoho Writer doesn’t appear to allow mail merging from a Zoho Creator database,
so building this functionality in a single product might make
a lot of sense. Zoho Writer would then have a plug-in architecture to
merge from any API enabled database. Pretty powerful.

A working integration with Salesforce.com would be pretty easy to build. It would be easy to put a Zoho Mail merge button in the activity history section of all your records. The code it would call would have to do this:

1. Show an interface where you get to select on Contact/Lead and one other object to reference, prefilling those fields with the current object you are coming from.
2. Show your Zoho.com Salesforce.com templates and allow you to select one. This would require you to log on to your account, which could be handled in different ways.
3. Grab the Zoho.com template you select, find all the merge tokens, replace them with the correct data, and open a new Zoho.com document with the merged text.
4. Optionally create an Activity in Salesforce.com to record the mail merge.

For building out templates, they would need to create:

1. A way to flag documents as Salesforce.com templates. Could be as simple as a tag, like “SaleforceTemplate”.
2. A way to insert merge tokens into a Zoho.com document. These are text elements like “{!Opportunity.Amount}” so could be done by hand (not user friendly) or through a simple UI driven by the Salesforce.com API. This second approach would require a user to specify their Salesforce.com user account–something that tons of partners have already built in some fashion. Even more generalized, a user could have multiple online database accounts that they could pull merge tokens from.
3. Add support for Opportunity Line Item, which iterates over all the Products associated with an Opportunity. This is really important for itemized invoices and the like.

This would be immediately helpful to me and my users who don’t have access to Windows and Word, with additional benefit for people in distributed setups where Office 2.0 is already in place, or makes a lot of sense.

I’m sure Zoho.com and Ismael have lots of thoughts about what a Zoho/Salesforce integration looks like. Here’s my two cents on one feature that I’d love to see.

When you’re researching constituents (donors, community leaders, politicians) you’re probably using the web. Google is now a verb, for heaven’s sake. But if you find juicy tidbits, it would be nice to add that info to a person’s record in Salesforce, where it will become part of your complete picture of them. So I created a simple bookmarklet that will grab what you’re looking at and open a create new Task form already populated with what you’ve highlighted on the page.

Drag this to your bookmarks toolbar.

After creating the bookmark, you’ll have to change two things in the URL:

• Use the right na# at the begining of the URL
• The first field passed is the URL field. Tasks don’t have a URL field. This bookmark will work without one, but won’t capture the URL anywhere. You’ll have to create a URL field and put it on the page layout. Then get the form field name (which will be a nasty guid) and replace it in the bookmarklet to correctly record the URL in the task

To find the guid for the field name, you can use a cool tool that Ron Hess pointed me to a while back.

In Firefox go to Salesforce.com and hit a New Task button on an Account. When the edit form for the task loads up, go to Tools | Page Info in your browser. Hit the Forms tab and it will list all the forms on the page. You care about the EditPage form. Select that and it will list all the form fields. One will be labeled whatever you named the custom URL field, but will have a guid for a name. Grab that guid and put in the bookmarklet, replacing the guid right after salesforce.com/00T/e?.

Once you get it working, you can prepopulate a new Task form with web information. Then just relate that task to a Contact and/or another object and save. Your web research is then in Salesforce.com. Easy as pie!

We build websites for groups in the Plone content management system. ZEA Partners, the European Zope/Plone organization, wrote up a brief case study of our work. Jon Stahl has a bunch of quotes in the article,

Open source communities and nonprofit organizations are a great fit. We are both passionate, mission-driven and have strong commitments to sharing, collaboration and social benefit. We’ve benefitted tremendously from the hard work and experience of the Plone community, and we’ve tried to give back in kind.

While Salesforce.com isn’t open source, they show a desire for openness with the way they look at their platform and your data. We’ve been working to help create a sharing community around use of the platform at nonprofits–I’m pretty pleased with where things are at this point, even if we’re nowhere near as advanced in size and collaboration as the Plone community is.

None of our processes up till now have handled real money. In this post we’ll look at what happens when the check comes in.

Processing money is where organizations start to differentiate their processes. For example, some groups have Memberships, where a donor gets an annual term and some level of member benefit. A key part of managing members is managing their expiration dates, and making sure memberships don’t lapse. Other groups just take donations that are generally on a yearly cycle–if a donor gives $100 in June 2005, it is considered a loss if their next gift doesn’t come in by June 2006 for at least $100.

This process map (Fig. 1.) starts with a check and the decision if the gift is a donation or a membership. Then we check to see if this is an expected payment (it’s already in the system) or one we weren’t anticipating.

Fig. 1. Processing the money when it comes in is where things start to get a bit complicated (PDF)

The gift then gets connected to an appeal, to help us determine the source of the money and also allow us to measure the return on those outreach efforts.

The last, and very important step, is to create a new gift 12 months out. This gift will be marked as “Prospecting” so we know it’s not a check that came in, but rather an opportunity for revenue in the future. By doing this, we’ll make sure not to lose track of this donor and their potential gift. And we’ll also inform our financial forecast for the next year. If you put all your potential gifts on the calendar, you can then see what your revenue picture will look like (Fig. 2.)

Fig 2. Some sample data representing all gifts for 2007. Red indicates gifts that have been received. Blue indicates gifts that have not yet been solidified.

As you might imagine, this can be very helpful in the budgeting process, and in dealing with cash flow issues. Most groups have their giving weighted heavily toward the final quarter of the year, as in this graph. By forecasting potential revenue, that picture becomes much clearer and can be managed more effectively.

Update: All process maps are now available in PDF format in links below the figures.

This is part two in a series of posts about the processes I’ve seen in the environmental nonprofits I’ve been working with.

In part 1 I showed processes for moving new donors through the ask process. In this post we’ll look at renewing major donors, and how to follow up on pledges that have been made by donors, but for which payment has not yet been received.

Fig. 1: Process for moving renewing major donors through to giving (PDF)

Dealing with renewing donors always starts in the database since renewing donors have already given to the organization (Fig. 1). Starting from a list of donors who are coming up on renewal data, the process is very similar to that for new donors. It is generally shorter, however, since these donors already know something about the organization. Solicitors can be involved, and the flow generally looks like the new donor flow.

Because these people have a deep relationship with the organization (deep enough that they have given money anyway) communication with the donor should be specifically tailored to that relationship, so the process captured is very generic. In this process, some groups I have worked with always ask for names of friends and relatives who might be interested. This is a great way to expand the social network of your supporters.

We end at the same place we ended before, with a donor committing to give, or choosing not to give.

If a new or recurring donor commits to give, we record the pledge as one of the last steps in the ask process. There is often a delay between the pledge being made and the payment coming in. This next process handles follow up on open pledges.

Fig. 2: Process for following up on pledges (PDF)

The donor management staff starts with a list of all recorded pledges that are approaching or past their donation date (Fig. 2). With each pledge, the decision has to be made if follow up at this time is called for. It’s a case-by-case decision that has tons of factors influencing it.

If the pledge is followed up on, gather the response from the donor and record any changes they’ve made to their pledge (payment date, amount, etc.)

Then the org will go back to view unpaid pledges at some point in the future that makes sense for them. Any pledges that have been paid won’t be on the list any longer–they’re no longer outstanding. This review is ongoing.

In our next installment we’ll look at processing payments that come in. We’ll start with handling checks that come in the mail, then get more complicated, with handling online gifts that are made at an external system, as well as gifts that are broken into multiple payments.

Malcolm and I made this today.

Salesforce.com started as a B2B selling application. So, Opportunities had to be related to an Account. You couldn’t do it any other way. Tucker MacLean of Salesforce.com just emailed me that if you go to the Opportunity page layout, you can now turn off the requirement for Account.

What does this mean? Individual gifts don’t need to be associated with an Account. We can use Contact Roles to connect them to Contacts. Organizational gifts can still be associated with Accounts, to show business donations, grants, and the like. We haven’t tested all the way out to see what the ramifications would be to ditching the Account requirement, but initial tests look good.

It also shows that now more than ever, Salesforce.com should to publish a detailed changelog with each release. Feature lists are great, but there are tons of bugs and feature changes that don’t rise to the level of a blurb on success.salesforce.com. Some of these small changes have big impacts. A changelog could be a 500 line text document that most folks wouldn’t read, but some of us would and it would help us use and implement the platform better.

Salesforce.com also patches the system between major releases–I’d love to see a changelog for those as well.

On Monday I had a great chat with Jim Yu, Director of Platform Product Management, and Adam Gross, Director of Developer Marketing, from Salesforce.com. Last week I posted some frustrations I was having with the Appexchange and Jim contacted me to talk about what I was experiencing, some possible workarounds, and to get a better sense of the way I was trying to use the service.

I learned a lot about how package validation in the Appexchange currently works:

1. Any explicit Id string is checked by the validator. Pretty trippy if you think about it. So an S-Control with var RecordTypeId = 0000004f500Fgh; in it won’t be packageable.
2. Any use of merge fields is checked by the validator, so if your S-Conrol has var Fund = “{!Opportunity.Fund__c}”; that field will be automatically pulled into to the package.
3. Using custom fields in any other way isn’t validated. SOQL statements that reference custom fields are not checked, and won’t automatically package custom fields. Same is true for set statements.

These insider tips were really helpful to me. If I want to share S-Controls that access the Fund custom field on Opportunity, as long as I don’t use the merge fields other nonprofit template users will be able to install things no problem. And I already talked about the solution to the record type problem.

I had two other take aways from this conversation. One is that Salesforce.com genuinely cares about what users think about their application. They want users to be successful, and also want to learn from folks who are looking at things from a slightly different angle.

Second, Salesforce.com seems to be genuinely interested in the shared development model, and is starting to think about how to enable an “open-source-like” development experience for Salesforce.com add-ons. I know Steve Wright at the Foundation is really behind this, and I think the developer side of the company finds it very interesting, too. We’ll see where it goes–the nonprofit Salesforce.com community would be some of the first to come to the table if this happens.

Update: Kingsley had the great idea in the comments that I create an entry on ideas.salesforce.com for this idea. If you want a changelog, go vote for it!