Perspectives on Salesforce.com

Tony Stubblebine just posted part 2 of his 3-part series on how to build and distribute applications on Salesforce.com’s AppExchange. The series is being published on the O’Reilly Network. Links have been permanently added to my blog sidebar, but here they are again:

Part 1 of 3 – An Introduction to Salesforce.com’s AppExchange: Tony lays out the basic information that any developer should know to get started. This article provides some context and points to how a developer can get their hands on a free Developer Edition account.

Part 2 of 3 – Using the Salesforce.com API: Tony explains how the Salesforce API works by creating a PERL script that automatically creates Salesforce.com Leads for every comment posted on a blog. This is a well-rounded example because it explains how to use the API and also how it impacts the back-end (inside Salesforce).

Part 3 of 3 – Packaging for Salesforce.com’s AppExchange: Tony continues building the blog-to-lead application by walking through the process of packaging and uploading to the Salesforce AppExchange.

I submitted an entry on IdeaExchange today about adding more authentication to the API to avoid rogue applications/people from wreaking havoc in your system and to provide a means of tracking the applications that modify your data.

Someone with average programming skills could cause some destruction via the API if they wanted to and I think some mechanism of locking it down further would be good. Also, since so many applications will be accessing/manipulating data via the API, it’d be good to limit what an app can do (e.g. only access specific objects, read vs. write) and also to track the application that is making changes to records. It’s like having application-specific profiles. When a user logs into Salesforce via a external application, they only get the permissions where their user profile and the application’s profile match (maybe they have delete Account rights in their user profile, but the application profile doesn’t allow deletes. They won’t be able to delete Accounts when using that application).

I don’t have the design all figured out, but it’s the idea I wanted to get across. I am interested in what you all think. If you have an opinion (agree or disagree), please add your comments to the post on IdeaExchange.

http://ideas.salesforce.com/article/show/42227/API_Authentication_List

As was reported before me (salesforcewatch, salesforce collective), the Winter release looks to be planned for Friday, January 12. I assume they will take that weekend to get it up, running and ready for Monday, the 15th.

The email I received states they will begin at 6:00pm pacific time on the 12th and end 2:00am on the 13th. I assume the exact times will be different for their different servers. The email I received was for NA3.

Foodservice Rewards is using my Google Maps mashup to allow people to see which distributors participate in their program.

They announced it in a seminar last week to their manufacturers and received very positive feedback. Here is their blog post announcing it.

Go see the functionality on their site.

For more information on this functionality, please visit the product page on arrowpointe.com

MapQuest recently released a mapping application on AppExchange. This is a free application that lets you map an Account or Contact (like you would using the default link to Yahoo! Maps), but adds a cool new feature on the landing page that allows you to find nearby Accounts and Contacts. Pretty slick. Chris Kramer has a good write up on it here.

This obviously has some overlap with the mapping work I do with Salesforce.com and Google Maps and it also attacks it in a different way.

I can think of many possible approaches towards mapping data and many different user experiences Salesforce.com users would enjoy. How do you choose one?

What do you think? What would you like to see in an application that maps Salesforce.com data? How would you design it?