In Part 1 of this series we lightly covered the core concepts of the Person Account feature within Salesforce.com as well as began presenting some helpful utility classes to aid in the programmatic conversion of traditional Contacts & Accounts into a Person Account.  Part 2 of this series will dive deeper into some additional utility classes

Now, go ahead and create a personAccounts class where we will place additional method including the migration method.

global class personAccounts {

Notice that the class is declared as global.  In next month’s blog, we’ll be adding some WebService methods that require the class to be global in scope.

Since Person Accounts have a separate RecordTypeId from other Accounts, we’ll need a few utilities to return the IDs.  You can use the IsPersonAccount field on the Account object to determine if an Account is a Person Account or not, but you’ll see that when we go to migrate to a Person Account, you actually need to update the RecordTypeId on the Account from that of a non-Person Account to that of a Person Account.

    // Return the Record Type ID for a Person Account

    public static ID personAccountRecordTypeId() {

        return [SELECT Id FROM RecordType WHERE SobjectType = 'Account' AND Name = 'Person Account'].Id;

    }

    // Return the Record Type ID for a (any) NON Person Account

    public static ID NONpersonAccountRecordTypeId() {

        return [SELECT Id FROM RecordType WHERE SobjectType = 'Account' AND Name != 'Person Account' LIMIT 1].Id;

    }

Now, there’s one more utility method that we need for our migration and I’m including it in the personAccounts class because it’s too specialized (it selects fields that we specifically need for the Person Account migration from an Account) to be placed generically in an AccountUtilities class.

      // Return a Map of IDs to Accounts for a Set of AccountIDs

      private static Map<ID, Account> AccountMap(Set<ID> AccountIDs) {

            Map<ID, Account> newMap = null;

            if ((AccountIDs != null) && (AccountIDs.size() > 0))

                  newMap = new Map<ID, Account>([SELECT Id, OwnerId FROM Account WHERE Id IN :AccountIDs]);

            return newMap;

      }

Now that we have covered the utility classes, Part 3 of this series will begin to present the actual migration classes that will be responsible for the logic required to perform the actual conversion.

Out of the box, Salesforce is configured to be used as a Business to Business (or ‘B2B’) solution for managing Accounts and Contacts (among other things).  Your Contacts are either linked to an Account using the AccountId field or they are standalone Contacts, which I like to refer to as ‘orphans’.

If your business does business directly with customers in a Business to Customer (or ‘B2C’) relationship, managing your customers using Accounts and Contacts can be cumbersome because some information you want to retain about your customer, such as an account number, makes sense to exist at on the Account object and some information, such as an email address, makes sense to exist on the Contact object.

Fortunately, a feature exists in Salesforce called Person Accounts which, depending on your Salesforce edition, may be enabled upon request for your org.  Person Accounts are really a marriage of an Account record to a Contact record so that you have the appropriate fields available in a B2C model.  Person Accounts use Record Types to differentiate between a Business Account and a Person Account.  For more information about Person Accounts, click the Help Link from within your Salesforce org and search for ‘B2C Overview’.  You’ll want to read up on Person Accounts and familiarize yourself with them before having Person Accounts enabled in your org.

A common thing to want to do in Salesforce once you have Person Accounts enabled is to convert or migrate a Contact to a Person Account.  The only way to do this is through the API so you will either have to create a custom button or link that uses an OnClick JavaScript to do the work through the AJAX toolkit, or you will need to do so in Apex code.  I have seen an OnClick JavaScript button that attempts to do this by simply updating the RecordTypeId of the Account, but there was no error checking in that script and as you will see in the sample Apex code provided, there are many requisite steps required in order to successfully migrate a Contact to a Person Account, one of which is to have a Contact whose AccountId is set to an Account where the Contact and the Account are in a 1 TO 1 relationship with each other.

While we will cover this topic in three parts, this first article will help set the stage by covering a number of utility classes that are used by the class we will create for handling Person Accounts.  Parts two and three of this series will build off of the topics presented here, by leveraging them within the migration methods themselves.

The ContactUtilities Class contains the method AccountIdSet which returns a set of Account IDs given a list of contacts.

public class ContactUtilities {

      // Return a Set of Account IDs that a List of Contacts belong to

      public static Set<ID> AccountIdSet(List<Contact> Contacts) {

            Set<ID> AccountIDs = new Set<ID>();

            if ((Contacts != null) && (Contacts.size() > 0))

                  for (Contact c : Contacts)

                        if (c.AccountId != null)

                              AccountIDs.add(c.AccountId);

            return AccountIDs;

      }

}

The UserUtilities Class contains the method InactiveUserIdSet which returns a set of User IDs where the User IsActive checkbox is false.

public class UserUtilities {

      // Return a Set of User IDs that are Inactive

      public static Set<ID> InactiveUserIdSet() {

            Set<ID> UserIDs = new Set<ID>();

            List<User> Users = new List<User>([SELECT Id FROM User WHERE IsActive = false]);

            if ((Users != null) && (Users.size() > 0))

                  for (User u : Users)

                        UserIDs.add(u.Id);

            return UserIDs;

      }

}

Part two of this series will continue our discussion on utility classes, rounding out the supporting cast before moving onto the migration classes themselves in Parts three and four.