In Salesforce, every Contact record must be matched to an Account in order to be viewed by your entire organization. Unfortunately, users uploading in new Contacts via data import, or entering a new Contact manually, usually forget to enter in an Account field. Later, when other users search for that Contact, they won’t be able to find it, as Salesforce considers a Contact to be private (and thus not searchable), if it’s not linked to an Account.

Since the Account field on Contacts is standard, we can’t just modify it to make it a Required Field. Oddly, creating a Workflow to specify an Account when one doesn’t exist doesn’t work, for reasons that are a bit of a mystery to me. Enter Triggers: a programmatic way to take some action before or after a record is created, updated, or deleted.

First, create a generic Account that can function as a catch-all. I suggest “Individuals”. Then, use either the Apex Deployment Tool or the Force.com Toolkit for Eclipse to create a new trigger (using those tools will be the subject of future posts).

trigger SetDefaultAccount on Contact (before insert) {
    For (Contact nc:Trigger.new) {
        If (nc.AccountId == NULL)
            nc.AccountId = [select Id from Account where Name = 'Individuals'].Id;
    }
}

The code basically says: “Before a new Contact is inserted and if it doesn’t have an Account Id, set the Id to the Account named ‘Individuals’.

In Eclipse, you’ll be prompted to provide some test coverage for the trigger before deploying:

public class testcontact {
    static testmethod void mytest1() {
        Contact c = new Contact(LastName='test lname');
        insert c;
    }
}

Awesome! Now you’ll never have to worry about anyone in your organization forgetting to link a new Contact to an Account.

Hat-tip to Mike Rosa @ Salesforce.com for helping me out with this.

Well, lucky you! You’ve stumbled upon this weird, strange corner of the Tubes. A place where the idealism of an elegant open source project meets the stone-cold reality of delivering quality software within tight deadlines to those who line your pockets. No, this is not just another Rails blog. This is a blog about building web software really fast, under ridiculous constraints, with a multitude of crap hurled your way, and finding joy in it. I don’t profess to have found that joy yet, but hopefully, in what should be a long, fulfilling journey, you and I, my dear reader, will. And I won’t ever use that many commas in a single sentence again. Promise.

Luckily, we have some excellent tools at our disposal. You’ve heard of Ruby on Rails, the high-flying web framework that everyone’s been writing about since 2005. It’s got that guy DHH who drops the F-bomb a lot and has a funny Danish accent.

The hippest nerds flock to it, because it’s a damn good way to built web applications. Ruby is, hands down, the nicest language to code in. Rails (and now Merb), were designed from the ground up to make the lives of web developers better. To make us happier. That’s an amazingly progressive goal, hippy-ish really, and it would have been laughed at by those IBM engineers of yore who wore thick-rimmed glasses out of utility and not out of fashion. But I’ll be damned if I ever code in PHP or Java again.

You may have heard of Salesforce.com, the enterprise CRM system used by Fortune 500s to Mom and Pop shops to everyone in between. In the past few years (as Rails has been gaining in popularity), Salesforce has become more than just a CRM (customer relationship management). Dubbed Force.com, it’s become a nearly full-blown web application framework, but not in the same sense as Rails. Using Rails, we build web applications by firing up a text editor and coding in Ruby, HTML, CSS, and some Javascript. Using Force.com, we don’t build applications as much as customize the hell out of an existing one. Much is already built for us, but we then need to use a gaggle of technologies to tweak it just right to fit with our users’ needs.

Ruby on Rails and Force.com have a lot of differences. Rails is open-source, licensed under the MIT License. It’s free as in beer and free as in speech. Force.com is completely proprietary. Your users will have to subscribe in a per seat/per month arrangement. You host (or pay to someone to host) your own Rails apps, while Force.com apps are completely managed by Salesforce.com (the company). Philosophically, Force.com is a true enterprise framework, while the Rails Core team could care less about making it enterprise (and with good reason).

But the two have one striking similarity: they both help web developers build solid applications in ridiculous time. And let me make a bold claim: Force.com completely destroys Rails in development time. It’s not even close. A tool that takes me a day to build using Force.com would take at least a week (and probably two) if I were to use Rails.

I’ll let that sit with you, as I’ve said enough for now. In the coming days and weeks, I’ll be evaluating the pros and cons of each web framework, and sharing what I learn along the way. Neither is perfect, but both are pretty great. While there are many great Rails blogs out there, there is (to my knowledge), only one regularly updated Salesforce development blog, with another newer one. So, I hope to help fill that void. If this all tickles your pickle, consider subscribing to the feed.