function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
gsickalgsickal 

Record Types - Should We Avoid?

I remember hearing several tips given at last week's developer presentation by DaveC (DevAngel) on developing with salesforce.  One thing that was especially important was to try and not used customized standard objects since these could not be deployed on the AppExchange.  Why is this again?  I understand that because they are standard objects, others can customize them as well, but if your code checks for the prescence of your own custom fields and behaves accordingly, why should this make a difference?
 
Secondly, it was mentioned that you should "avoid using record types".  I can't remember the reason for this, but was wondering if you could provide more insight on why this is suggested... thanks
DevAngelDevAngel
You don't want to use customized standard object because of the packaging/unpackaging process. Since at this time we cannot guarantee that the instance that you are installing into does not have a custom field with the name you chose already, we can't package it.

Ex> Customer has a lat field on account that is a boolean (lazy user didn't want to name the field late as in late payment). Your appexchange app could have a custom field on the account called lat that is a number to indicate the lattitude of the account address. Who wins? Don't want to hammer a customers customization, and if we left it the boolean, your app wouldn't know what to do with a boolean since it was expecting that field to be a number.

Record types I believe are ok on custom objects that you create, but not on standard objects. Not sure exactly why, but I'm sure it's a related issue to custom fields on standard objects.
gsickalgsickal
This answers my question precisely.  Thanks!
andyCandyC
As I've just frustratingly found out when attempting to publish an app, "Custom Objects with Record Types are not supported." - that's why you should "avoid" them.

Also, surely the argument for naming conflicts on Standard Objects Customisations is exactly the same as for naming conflicts on Custom Objects. If I have an object called "School" in my App, and the customer does too, then the install will and should fail.

You get us round this by forcing a naming convention on the custom object by way of a 4-char ID prefix, why can't it be the same on a standard object customisation ?

Us guys out here really need some idea of when these 2 vital bits of functionality can be deployed ie:

Standard Object Customisations
Custom Object Record Types

I may have to wait to deploy my app (rather than rewrite it) until these are available, but I hope you are planning some interim releases, because Summer 06 seems a long way off.