Salesforce.com employee Ron Hess took the Timeline S-Control that I built last year and rewrote it. It’s a thing of beauty now and it’s free for the installing. Just put it on the detail page for Contacts, Accounts, Opportunities, and Cases and see all the relevant info in a left to right, scrollable Timeline.
This needs to be seen to be believed. You basically add a whole new way of navigating data by installing this package. Really shows the future of mashups as UI elements.
Thanks again to the folks at SIMILE and thanks Ron for making it awesomer than I ever could.
I was a part of some conversations today about software integration. We were talking about integration and how it’s important to solve the problems that nonprofit staff are having today. A lot of work processes can’t be completed in one software platform. You often have to jump to another platform midway through a process. For example: you look up your recent donors in your CRM and then you want to send a blast email to them. That’s a place where you may need to leave your CRM and take your donors over to an email blasting tool.
So integration can make those bridges between software invisible, or at least easier than the manual options of hand entering them, or doing an export and import. But what does integration really look like? In doodling in the meeting I came up with some drawings that helped me get my head around it.
First we’ve got platforms. These are the software applications we’re looking to integrate. Next, we’ve got web APIs. This is a way to make the platform do things from a distance, over the Internet. Then we’ve got custom logic and UI to make the integration happen. The logic implements the business rules–when x happens, then do y, finish with z if y was successful. Sometimes UI can be helpful in an integration like this, sometimes it isn’t necessary.
On to the doodles.
Doodle 1: One platform with no API integrating with another that has an API
When I integrated dotproject with Salesforce I used this method. I built logic and UI into dotproject as custom code. It would then speak to the Salesforce.com API, doing what I wanted it to do. It could manipulate dotproject data and/or Salesforce.com data according to the business rules I created and hard coded into the logic.
Pros: Can get integration with only one API. UI is embedded in one of the platforms, so the interface can be seamless. No outside server to run.
Cons: Have to host the code in the system without the web API. The integration may break if the underlying platform code changes.
Examples: my dotproject integration, What Count’s email integration with Salesforce.com.
Doodle 2: Integrating two applications with APIs via an external client
If I have two platforms with web APIs, I can write UI and logic by which someone can manipulate both systems. That code and UI can live anywhere on the web. It could be PHP code on a web server, for example. Or it could be a dedicated integration server that can be configured to support your business process and connections to the services you care about. Jitterbit is an open-source example of this.
Pros: Depending on complexity, client can live anywhere: your desktop, a webserver, your phone. Integration code is portable–can be moved around as necessary.
Cons: Need to run it somewhere. If it needs to have high uptime, someone is responsible for that.
Examples: Polling a CRM looking for newly places sales orders and then turning those into work orders in another system.
Doodle 3: Integrating two applications with APIs via code embedded in one application
Salesforce.com, for example, allows me to embed custom UI and logic in their system. This is a lot like the first example but instead of making calls to underlying code, all calls go through the web API.
Pros: UI is embedded in one of the applications, so the interface can be seamless. Don’t need outside server to run.
Cons: Code isn’t portable, has to live in one service.
Examples: Not sure if I can come up with any examples here that I’ve seen.
Discuss the doodles.
The Winter 07 release is amazing in it’s depth and breadth. It’s great for me in my role as consultant because I have fewer places in the applications I build where I have to explain some weird workaround to users. “I know it looks like you should click there, but NEVER click there.” Some of the biggest issues I had with Salesforce.com as a platform for building nonprofit databases went away overnight in mid January.
But if you look at Salesforce today, you’re eyes will be drawn to one major area of the application that has lagged so far behind it has become a blemish on an otherwise phenomenal platform. I am, of course, speaking of Campaigns.
Campaign is a standard object in Salesforce.com that is used to model outreach efforts. I use it to group people for a direct mail appeal, or list the people I invited to a conference, or flag folks who are on my current prospect list. In addition to grouping people together, you can also associate Opportunities with Campaigns, which means you can easily see ROI associated with outreach efforts. This last appeal to 2000 people netted $3500. Was it worth it?
The concept is really flexible. Because Campaigns can have people as Members, they can be any ad hoc listing you want. And they become more powerful in Winter 07 because you can feed them into the Console for the exact view of your constituents you want.
But there are some things about Campaigns that need to be updated to give it power and flexibility on par with the other Standard objects. Here are my suggestions to the Salesforce Campaign team:
Where is the Member Related list?
I mentioned earlier that Campaigns can have Members. But, there is no Member related list on the Campaign object. If you want to view the members of a Campaign you have to load up a report (which you can’t even pass a Campaign Id, by the way). It’s the only object that behaves this way. How about handling Campaign Members like all the other related lists? Show me 5 and let me add some more if I want. If I have 200,000 people on a Campaign, I’ll get bored before I crash your servers with requests.
What’s with the marketing User checkbox?
To turn on the Campaign functionality for a User, you don’t go to their profile page, where you control their access to all other objects in Salesforce. You check the Marketing User checkbox on their User object. It’s the only object access property that’s handled this way as far as I can tell. How about everyone being a Marketing User if they have permissions to it in their Profile?
Sharing is good behavior
Accounts, Contacts, Opportunities, and Leads all have ways to hide certain objects from certain groups of people. A great idea when your Salesforce.com system is used by the whole company with many different job functions. There are no sharing rules for Campaigns, so you either see everything, or nothing. It sure would be nice to have some control there.
Customization is your buzzword, how about showing Campaign Member some love?
When you associate a Contact/Lead with a Campaign, you do it via a table called Campaign Member. The only metadata I get to record about this relationship is a text field called Status, and a field called Responded (a true false that calculates the response rate). So someone has been “Invited” or “RSVP” or “Attended”. But there’s no good way to say, “Joe is attending and he wants to bring 5 people.” You can’t say, “Susan said yes and she’s willing to carpool to the event.” Crazy long-tail needs, I know. But that’s what Salesforce is good at. How about letting me add custom fields to the Campaign Member table? I’ve said before that this alone would turn Salesforce.com into a viable Event Registration platform.
Active checkbox
And now for a little one that is amazingly annoying. When a User creates a Campaign and saves it, they won’t be able to find it unless they remember to manually check the Active checkbox. It’s a great way to keep people from utilizing the Campaign functionality because the first time they try it out they have no idea where their Campaign went. How about letting an Org choose if it’s on or off by default?
So I’ll I’m asking is that Campaign becomes a first-class object, to use Salesforce internal lingo. User got the makeover it was needing in Winter 07. I’d love to see you roll away the bus in front of Summer 07 and see the current Campaign object with an added second floor, new sod, and a pool in the backyard with a pirate ship in it!
Update: Chris suggested in the comments that I link to these ideas on the idea exchange, so those links have been added. Vote ‘em up if you agree!
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.
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.
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?
What are the main benefits?
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.
Salesforce.com to go carbon neutral in 2007 with a program they’re calling Earthforce. It looks like their plan is to offset their office, travel, and datacenter use of carbon by funding projects with Clean Air - Cool Planet, NativeEnergy, and Conservation International. Benioff said,
At the Salesforce.com Foundation, we have always been dedicated to social responsibility, and Earthforce is an important initiative to spearhead our efforts to help the environment. By offsetting our carbon footprint, we are moving further on the path toward sustainability and engaging our community in contributing to effective solutions for the climate crisis.
Bravo Salesforce.com in continuing to be a model corporate citizen.
Update: More details on Salesforce’s commitment to carbon neutrality up on their Foundation site.
gokubi.com is proudly powered by
WordPress
web hosting
