Using the + Sign in Email Logins

Last Updated on Tuesday, 24 January 2006 08:31 Written by Steve Tuesday, 24 January 2006 08:30

Most applications on the web require that you create a username and password, and many have gone to using an email address as the username. This is nice because it’s easy to remember, but it can be hard if you want to have multiple accounts on one system. To have multiple accounts, you have to come up with multiple email addresses, and they have to be real addresses because there is usually a validation step where they email you something to respond to.

Salesforce.com works this way. Of the 300K+ users on their system, each one has a unique email address. For most of these users, they use their work email and they’re done. I, however, have the problem of needing a login for my organization’s Salesforce.com database, one for my test database, and one on each of my client’s databases. Right now I need 5 accounts in Salesforce.com, which means 5 valid email addresses–a real nightmare.

Good news is that there is a neat trick with email that can get you around this problem. When processing addresses, if a mail system runs into the “+” sign before the “@” sign, it will skip to the “@”, effectively ignoring everything that comes after the “+”.

Example:

Bob@testemail.com looks exactly the same to a mail system as Bob+anything@testmail.com. Email to either of those addresses gets delivered to Bob@testemail.com.

The great thing is that systems like Salesforce.com see those email addresses as different, so Bob can use them as logins that deliver to one real email address, thereby getting past the problem of having to set up multiple “real” email addresses.

Application Features vs. API

Last Updated on Thursday, 19 January 2006 12:44 Written by Steve Thursday, 19 January 2006 12:25

Interesting article over at Skype Journal talking about the Skype application and how the API stinks. Their main point is that an API can be tacked on to an application, or can be the core on which the application is built. If an application is built with the API at the core, it can become a platform that others can build on top of. If the API is an afterthought, it will not empower the greater community of developers to adopt the platform and extend it beyond what the application developers can do. They posit that Skype hasn’t embraced the API and won’t take off as a platform until they do.

A lot of applications are playing API catch up right now. You almost can hear the CEO saying at staff meetings, “We need an API for web 2.0!” They have a long way to go to catch up with Google, Salesforce.com, and others who have realized that the API is key to putting power into the hands of developers. And by giving outside developers power, they give their application huge competitive advantage.

Interesting API as Platform tidbits:

• Google released a feed reader application a few months ago. Frankly, it was a pretty lackluster application that lacked a lot of usability and functionality in other tools like Bloglines. But then I heard the real story–Google built the news reading API first, then built the reader app on top of that as a proof of concept. To them, the API is the important product. Wow. That is commitment to the platform, not the application.
• Fully half of the traffic that hits Salesforce.com’s CRM application does not come to their web app–it accesses the API. Half of their traffic could care less that the web front end even exists.

To the application builders out there: Do you have your API closest to heart? Or are you building your functionality first, and creating the API later? Firefox and Chandler are two examples of open source software projects that focused on API in their early stages. Problem was, neither had any features to show for at least the first year of their existence. That stunk in the short term, but look where Firefox is, and a lot of it’s popularity comes from the Extensions that people build against their API. And what about Chandler. You haven’t heard about this project? In 3 years you will have–I think it’s going to be wildly successful because they are taking the API driven aproach.

API driven services are the future, and it’s one of the big reasons I chose Salesforce.com as our CRM platform. Power to the People!

New way to Handle Households in Salesforce.com

Last Updated on Thursday, 19 January 2006 09:40 Written by Steve Saturday, 14 January 2006 06:28

The new version of Salesforce.com changed the way you could relate objects to each other. I had an idea that this could be very powerful, but my naive realist brain needed to see it to believe it.

Indeed, this is very powerful. It has allowed me to greatly simplify the method I use to handle Households. I suggested that things might be better earlier, but they are much better than I thought.

I can now create one custom object called Household that can hold the address info for the house, and then I put a lookup field on a Contact that allows you to associate them with a single Household. Once you do that, there is a report recordset called Opportunites with Contact Roles and Household that you can use. It will give you all gifts by individuals, but groupable by Household.

Very nice, simple, not overly complicated. Interface is clean, and easy to explain. Now I just need to create an S-Control that is a form for creating a contact, thier Household, and their spouse all in one. Would anyone be interested in seeing that?

When I have a minute, I’ll be publishing my steps for setting up Households in Salesforce.com in a nice clean PDF.

[Update]: Here’s the promised PDF on how I set up Householding.