In the past, we’ve made no bones about pointing out that one of Salesforce’s biggest selling points is the customizability that it has. We’ve pointed out the various custom fields, record types, reports and other such things which can easily be created through its visual interface, and enhanced further by the exposed API. But, we’ve never really talked about the Salesforce custom object as a main topic before. For those new to Salesforce, or just starting to get into more advanced parts of it, the Salesforce custom object is basically a custom data table with specific column labels and value types. It’s a lot like creating special custom tables in a database. Actually, that’s exactly the same thing, just represented more contextually. Now, with the advent of technology like this, you might find yourself looking to get a good angle on this concept. You know what it is, but you’d like to know the best ways to employ them and use them properly. Unfortunately, there really isn’t much to be said for best practices with something like this, because it’s not really that deep of a concept in all truth. It’s really nothing much more than a custom data table with case-specific labels, data types and relationships. Now, while that’s not a deep idea, it’s a damn useful one for certain. You see, while there are a number of table layouts and record types that are configured and running by default with Salesforce. However, your industry is going to have specific records and analytics to keep track of that other industries will not. Find out how to create record types in salesforce. Well, Salesforce can’t account for those situational data components, so you need the ability to make a structure yourself for them to live in. This is where the custom object is useful, because that’s exactly what it is. You have your basic data types available, and it’s completely communicable with the Apex API, so custom objects can work with extensions or custom macros you’ve developed, to make this even more powerful. Now, one thing that I can advise with these is something I advise with other custom components in Salesforce. Before you create one, be sure to check and make sure that it’s not already made, or not something Salesforce actually can do from default tables. Following this, be sure to make certain that it is needed and will be used. If it’s just a “I had this idea”, make sure that kind of idle experimentation is permissible within your corporate culture before doing that. Finally, make sure that you also are obvious with its name, and make it available to those who need it and make sure everyone who needs it is aware of it. Along with this, distribute a document talking about the purpose of the data, if you can, so that developers and users know what the tables are talking about and where their data inputs from. You probably expected the tips for Salesforce custom object creation and use to be more complex and involving than this. Well, I hope this is a pleasant surprise, in that it’s really the same common sense procedures around their creation, as with most custom Salesforce gismos, that is where caution and thinking is needed. Find out how to create a custom object in salesforce.