It’s been awhile since the last comment and obviously now we’d be able to find numerous hosted solutions and companies that offer Salesforce and Quickbooks solutions. To add to the list, I’d like to mention a hosted solution by Apatar which previously was best known as a desktop application for intigrating data. Now it’s making the first steps towards SaaS introducing a web solution targeted at data synchronization between Salesforce.com and QuickBooks. You may also want to take a look at it http://www.salesforce.com/appexchange/detail_overview.jsp?id=a0330000005kn33AAA. It’s rather interesting to see if it’s possible for a company to have both a successful desktop and hosted solution))

OK, not that extreme. I have some custom objects I couldn’t live without. But not many.

Thanks for the tip on quickbooks integration. I suspected it wouldn’t easily map to what we’re doing, but hadn’t had a chance to look deeply at it.

A few of my clients have asked me to go with custom fields on the native object because it is quicker for their data entry staff. If someone is doing a lot of data entry at one time, being able to quickly tab through fields rather than having to save the record and then go down and do another set of data entry on a related list is a big deal. They are absolutely willing to have lengthy page layouts in exchange for data entry speed.

I’ve done enough data entry in my life that I can’t argue with them on this one! It’s not as pretty and cool but it’s easier on the carpal tunnel!

We have a few clients in the process of this but there is one fairly significant problem:

The integration tools out there (eBridge and SalesCentrix) both require that the sfdc set-up be using Products on and Opportunity. This is because QuickBooks functions based on line-items, and the only line-item capability in sfdc is on Products. I have talked to SalesCenrix about this and they currently do not have anything on their road map to change the tool to take data directly from the Opportunity object into QuickBooks. You must use Products.

So this becomes redundant data entry…if you’re entering a $50 donation as an opportunity record, you then have to scroll down and re-enter it again as a Product in order for the QuickBooks integration tools to work. This means bringing Products into the nonprofit equation which is not very palatable when we’re already trying to sell a for-profit tool to these groups.

The problem with custom objects lies in often not being able to create formula fields and reports that cross objects and get you the data you need. I have often started down the road of creating a custom oject for something and wind up scrapping it and building pieces out as custom fields directly within the native object so as to avoid reporting problems as well as get more out of custom formula fields.

Your discussion of pledges is a great example of this. I had originally built Pledge Payments as a custom related list on the opportunity object, only to discover that I couldn’t access the Amount field on opportunities in the caculated field I had created. The client and I decided it was best/easiest to simply build a set of custom fields on the opportunity instead, including the pledge installment #, the due date and the paid date, which allows us to then deduct the pledge payment amount from the opportunity amount to give us a remaining pledge balance.

The one thing folks will quickly discover about salesforce is that there is hardly ever one single way to implement it and the same issue may even be solved differently between different clients.

See you next week in Seattle.

~S

Take outreach for example. We could do outreach events as a custom object that contacts get related to. That would give us more flexibility in naming, and would make matching a nonprofit work process a bit easier. This, in fact, is how Events are handled in the nonprofit template that Salesforce.com hands out. But you could also handle outreach with the Salesforce.com Campaign object. You can’t do things the way you would with a custom object, but a lot of events could be handled this way. In January, Salesforce.com made some killer improvements to the Campaign object. Now you can take any report of Contacts that you can generate, and in two clicks you can add all those people to an outreach event. So, if you want to invite everyone who gave in the last year to your annual party, just make the report and two clicks later they are associated with the party invite. Incredibly powerful, and I’m using it now because I stuck with the standard object.

It’s always a trade off, and it’s not always clear the best way to go. But my philosophy is to start with the business process of the nonprofit, then try to model those with 100% standard objects. If not possible, I create as few custom objects as possible.

Sorry for joining this conversation so late in the game (traveling). Steve, your interoperability argument for current and future 3rd party apps is very convincing and has a lot of merit for larger orgs needing accounting integration.

As a whole, integration into third party products is problematic with how NPOs are using SFDC to track revenue. For one, there are always going to be variances to how NPOs use SFDC and out of the box integration solutions will not work (or will work poorly). Second, trying to adhere to a process meant for a commercial/corporate work flow model, does a disservice to nonprofit staff on all levels (data entry…confusing, fundraisers…not aligned) for the sake of technology integration.

I question how many smaller nonprofit would/could afford to take advantage of a integration product into QuickBooks. I think many would like to, but so far the solutions seem more trouble than they’re worth.

2cents

~S

It’s a big issue for us, but a bigger one for Salesforce.com as a company/platform. They have to move their application forward while not breaking anything for their 15000 customers. Not to mention all the add on products. Since Salesforce.com is an on-demand app, they can’t release a new version and not worry about backwards compatibility. Their new versions have to work with no migration, on day one. I’m glad it’s not my problem.

This is smart. But Sonny’s comment on your recent post to the effect of “prospects and payments are different — but related things” has got me thinking. I think Sonny’s right — these are (in folks’ minds) different business processes that should probably be clearly differentiated in Salesforce. I’m wondering if it might indeed be smarter long-term to use Opportunities for pledges and a custom object for gifts/payments, as Sonny suggests.

Not so much because you *can’t* do it all with Opportunities, but because of the semantic (and usability) confusion that I fear might result from using one strangely-named top-level object (“Opportunities”) to cover two functions that are “top-level” in a user’s mind.

The rest of this, about using Opportunities to track and schedule the plegde payments, I love. It is so cool to see these pieces coming together.