Adding emails to Salesforce when on a Mac

Last Updated on Thursday, 1 February 2007 11:48 Written by Steve Wednesday, 24 January 2007 02:58

Simon Fell, the brains behind the Salesforce.com API, has created a tool called Maildrop which:

provides the ability to take emails and create Case or Activity in Salesforce (ala Outlook edition). It works with both Apple’s Mail and Microsoft’s Entourage.

If you use either of these two mail apps, I’m sure this could make getting communications into Salesforce.com much easier for you.
Update: Maildrop now available on Appexchange.

Some thoughts on cleaning data before you migrate it

Last Updated on Thursday, 18 January 2007 05:35 Written by Steve Thursday, 18 January 2007 05:33

If you’re working with a consultant when migrating to Salesforce.com, they’ll work with you to build out your new database to support your needs. If all goes well, you’ll end up with an empty database that’s ready to fill with data about your constituents. Most projects will have a phase where your consultant (or you if you’re brave) will move data from your old systems to your new one. This moving of data is a lot like “fitting a square peg into a round hole about 100 times.” Fields need to be changed, combined, split apart, etc. This is one place I really think a good consultant can help.

Before you migrate your data, though, you can do some work with your existing data to get it ready for migration. Here are a couple tips that would help a consultant, and can save some time and money in the migration process.

Don’t migrate data you don’t need
If you’ve got a ton of data that is of suspicious quality, or utility, think about ditching it. We all know what a pack-rat’s house ends up looking like over time. Databases can accumulate the same kind of junk. Don’t migrate data just because you have it–make conscious choices about your data

Standardize if you can
If you have 15 lists of names in Excel that are very similar in structure, think about making them have the exact same field names in the same order. This change could save a couple hours in your data migration, and will actually make using those lists easier for you until you start using your new system. Consistency can really help when using data.

When you have multiple lists of people, make sure you treat their information in similar ways. If in some data sources you have the first name as “Bob and Sue” while in others you split that out, that’s extra work during migration. Same goes for address fields. Try to be consistent, and it might be worthwhile cleaning the data this way.

Consolidate if you can
Most groups have a database that is a list of most of their contacts. Most groups also have other lists that contain the remainder of their contacts. If possible, consolidating the extraneous lists into the main database ahead of migration can save time. This doesn’t always make sense, but might in your situation.

Think about hand entering some data
While this doesn’t make sense for the bulk of your data, it may be a good idea to not migrate a couple smallish data sources you have. Each new data source has an up front cost to figure out how to fit it into the new system. If a data source is only 15 rows of data, it might make more sense to enter those by hand after the fact. Plus, lining up some data entry after you cut over to your new system can give you some good repetitions with your new database.

Migration is a pain (for you and the person doing the migrating), with the added joy that it costs lots of money. No one really likes this phase of the project, but it’s critical to your success. A new system loses tons of value if you don’t maintain the connection to your organizational history.

So revel in your data migration and think about doing some cleaning work ahead of time if you have more time than money, and want the data migration phase to go as quickly and painlessly as possible.

Bye bye dotproject

Last Updated on Wednesday, 17 January 2007 10:35 Written by Steve Wednesday, 17 January 2007 10:35

I wrote earlier about our integration between Salesforce.com with dotproject, an open-source project management application. Well, after 3 years of using dotproject the integration is no longer. I’ve rewritten the dotproject functionality that we were using directly into Salesforce.com.

Integrations are great when you have multiple systems that each provide important functionality for you. What I discovered over time was that the set of project management functionality we were using in dotproject didn’t warrant maintaining the separate application and the integration. It looked like it would be easier to rebuild the key pieces inside Salesforce.com.

And that has turned out to be true. So, what did I build?

• A schema that adds Tasks to Opportunities. These Tasks are buckets for time tracking.
• A schema that adds Task Logs to those Tasks. These are recordings of worked time.
• Support for Invoices and payments to outside Consultants related to Opportunities
• An AJAX timesheet that makes it easy for a Salesforce user to record time
• Tools to make it easy to import Tasks from an existing Opportunity

What are the main benefits?

• Projects and time are in our CRM where the Organizations already are
• Projects are tracked as Opportunities, which is what they really are
• Timetracking is in our CRM as well
• I get to leverage the Salesforce.com reporting engine
• The timesheet for entering data has better performance than the previous PHP app we use. I am most pleased with this app–it’s pretty nice.
• Data is easier to maintain and modify because there is no longer an integration to deal with
• What I built is now simple enough that it would be possible to roll out for other Salesforce.com users who would like to track their time

Integrations are great when they provide benefits that outweigh their costs. We decided that this calculation was no longer positive, so we ditched the integration. In this case I think it was a good decision–time will tell.