Friday, April 29, 2011

keeping Person Accounts on the roadmap

From a discussion on Person Accounts yesterday, a Salesforce Foundation representative said about Person Accounts, "we do not have a roadmap going forward but the current offering is going to continue". What does this mean to us as Salesforce customers and prospective customers? One school of thought says that having no roadmap indicates that the feature is on its way out. Another school of thought says that having no roadmap simply means that at the current time, the feature meets most if not all of users' needs and has no need to be on a roadmap.

But let's stop for a second and think, "Why is this feature important?" My thought on that is, "Should a database be structured to match the business model?" To me, the entities with which we do business dictate whether we should use Person Accounts or not. If we contract and transact with other businesses, then accounts with contacts would work. If we contract and transact with individual people, don't person accounts make more sense? A simple use case is managing individual donors and contributors for nonprofits. Another use case is managing students at an institution of learning.

But perhaps most importantly, what are some of the pros and cons of using Person Accounts? I'll admit that I'm probably biased because we use Person Accounts in two of our orgs, but I hope not to lie when I say that I would love to know all of the benefits and liabilities of using this feature.

Below are starters taken from an editable document shared with the public, in lieu of something more authoritative from Salesforce.

Some pros:
  • The model fits the B2C way of doing business.
  • You can contract with people instead of businesses using the standard Contract object.
  • Person accounts will show up on both account and contact reports, which would be accurate for a company that mixes B2B with B2C.
  • Person accounts can leverage both Account fields and Contact fields via a single sObject.
  • Contact fields are directly accessible for a Person Account via Apex through a single Account instance.

Some cons:
  • To convert a lead into an opportunity for a new person account, the lead cannot have a value in the standard Company field.
  • For person accounts, formula fields at the account level cannot reference contact fields.
  • Code may have to account for the fact that there are now two record types on the Account object.

Personally, I believe that Person Accounts make a great selling point and feature for the Salesforce products. If being off the roadmap is a fault, then maybe we just need to promote some of the ideas on the IdeaExchange that will make the feature even stronger and more compelling:

Tuesday, April 26, 2011

Bug (?) with Rerendering an apex:pageBlockSection When apex:inputFile Exists Elsewhere on Page

I can understand throwing an error if we rerender part of a page that contains an apex:inputFile component, but I'm a bit confused about why rerendering part of a page that has no apex:inputFile component should generate the following error:
apex:inputFile can not be used in conjunction with an action component, apex:commandButton or apex:commandLink that specifies a rerender or oncomplete attribute.

I've created a demo for getting the error message, although you can't see the exact error message unless you deploy the page in your own sandbox. The source code can be downloaded here.

What I expected was that my partial page refresh of "Dependent Section" would work just fine. However, when I change the value in my controlling picklist, the page just fails, with the error mentioned above.

Is this a bug? I'm not sure what Salesforce would say, but it certainly is puzzling and extremely frustrating to me.

Tuesday, April 12, 2011

DML error: Name not specified

When trying to upsert a list of records via Apex, I received a slew of "Name not specified" errors on every single one of the records.  The Database.Error.getStatusCode() instance method returned "MISSING_ARGUMENT", and the Database.Error.getMessage() instance method returned "Name not specified".

My upsert was constructed as follows:
upsertResults = Database.upsert(applications,
        Application__c.Unique_External_Application_ID__c, false);

Application__c is a custom object, and Unique_External_Application_ID__c is a custom field that is set to be an external ID. applications is my List that I was trying to upsert.

Basically, after a few hours of frustration and asking for help on #salesforce, I determined that the error came from the fact that I was trying to set a Lookup field by specifying an external ID on the related object. An example is shown below:
Application__c application = new Application__c();
application.Start_Term__r = new Term__c(Banner_Code__c = '201115');

I had simply assumed this would work, since I knew that a lookup field can be set by setting the custom field __r to new sObject(Name = recordName). Apparently I was 100% wrong.


But I did create an idea out of this whole mess: enable Apex DML to set Lookup or Master-Detail by external ID

I wish I could recall the idea, because apparently the error was the result of my putting a null value into the Name field when specifying the related record. Essentially, my code was trying to execute the following:
application.Program__r = new Program__c(Name = null);

Specifying an external ID in the following manner does work:
application.Term__r = new Term__c(Banner_Code__c = '201115');