Cheek to Cheek

Last Updated on Thursday, 27 July 2006 09:46 Written by Steve Thursday, 27 July 2006 09:46

Appexchange is a really great system for packaging up modules for easy installing in Salesforce.com instances. But it’s not perfect–you can’t package up a lot of things you need to build out Salesforce.com for a customer. So, the current state of the platform still requires a lot of re-building. I spend too much time creating the same fields, same page layouts, and same profiles each time I work with a new client.

The only way it’s palatable for me is because I have two monitors on my computer and can pull up a completed Salesforce.com instance on one and my work in progress the other.

This makes the monkey work of creating the fields and laying them out correctly easier, because I’m not flipping between browser windows or looking at a printed page. If you do this kind of work, consider the $200 upgrade in video card and monitor to double the size of your desktop.

Appexchanging Reports and Dashboards

Last Updated on Thursday, 20 July 2006 09:32 Written by Steve Wednesday, 19 July 2006 02:00

I spent a bunch of time today creating some stock reports and a dashboard with the goal of using Appexchange to deploy them to my customers’ Salesforce.com instances.

Reports are time consuming to create, dashboards even more so. Here’s what I’ve learned in my first day trying to replicate for nonprofit functions what Scott Hemmeter has done for user adoption:

• Dashboard widgets sometimes don’t visualize the way you want–the axes may be reversed, or your vertical stack graph may be stacking what you want across the X-axis. I found out an undocumented feature: Create a Chart on the report you’re using for your dashboard (it’s the last step in the report wizard)–you have much more control over the display. When you create a dashboard widget on that report, it looks at the chart information and sets up your chart the way you did on the report.
• If you reference any custom objects, the object will be installed right along with the reports. That’s probably not desireable behavior, unless you package up reports with the install package for the objects themselves. Then the user gets the object installed, and the reports all at once.
• Don’t reference any custom fields on standard objects. Appexchange just won’t let you do it. My strategy is to use only standard fields–you can always add custom fields to the reports later.
• You can build reports that use record types, but they will be screwed up on install. I’ve got reports that look only at Gifts. After install, I have to open up all those reports and change the criteria to use the right record type–the reports won’t show any data until you fix that. A pain, but pretty quick.
• The and dashboards are installed in a folder with the same name that they came from. You don’t run into naming conflicts, but you do want to name the folders wisely.

I’m pretty excited as this is going to save me tons of time, and give me a way to share my reporting best practices. This approach will save me a ton of time–I’m glad I finally got around to digging in to it.

Feel free to install the reports and dashboard. Let me know what you think!

Some Observations on Nonprofit Software

Last Updated on Tuesday, 18 July 2006 11:55 Written by Steve Tuesday, 18 July 2006 11:55

Over on the ONE/Northwest site I’ve written up a piece about how nonprofits can best leverage existing software in pursuit of their missions.

Identifying prospects, communicating with them, and moving them along a path to engagement is a set of activities common to just about every organization in the world. Corporations call it sales and marketing, nonprofits call it donor management and outreach, and government calls it campaigning and constituent outreach. Underlying the different terms, the activities are very similar.

This is great news–we don’t have to build it ourselves! We get to use great free and paid software that is targeted at serving other sectors, primarily corporations. We can implement our engagement strategies using tools that are already designed to do that well.

Flexible, enterprise grade commercial applications with open APIs make it possible, and highly desireable, for a nonprofit to support it’s engagement processes with very little software that is written specifically for nonprofits. As the economic engine behind those enterprise applications moves forward, we get to slipstream along, reaping the benefits of their huge investment in the tools. It’s all about leverage, and investing where we can have the most impact, on that small percentage of functionality that the corporate market isn’t ever going to build.