As a Salesforce architect , admin or developer, we are always thrown into problem areas where we need to decide leveraging a custom object or a standard object for our business requirements. From a salesforce standpoint or best practice, it is always a standard object mantra which we had been preached all the time but it does not work for all the time. So the question is if we can leverage a framework which can help to make decisions on when to use a standard object or a custom object.

Here are the top key questions which would help you make the decision?

1. Will the standard object meet the data structure needs for your current application with respect to the relationship between entities?
2. Does the standard object meet the entity requirements for legacy application and what is the impact on data migration?
3. How does data access and security impact the decision on standard vs custom object design?
4. How does a well-architected framework fit into the decision of standard and custom objects?

Will the standard object meet the data structure needs for your current application concerning the relationship between entities?

In my use case, we debated leveraging the standard address object, location, and related objects.

If you look at the public sector object model, for every address, there is a need for a location and for every account, we need the associated location to connect an address to an account. In our use case, which is for a federal agency where we are talking about individuals( Person accounts), we need to have an associated location, a location to track the addresses of the person accounts. The key requirement is to track addresses of individuals. There was an another usecase for tracking presence locations of individuals with addresses of individuals. So if you look at it from an entity level, there was only individuals, addresses, primary locations and address related to the individuals. In the standard object model, the associated locations and locations have to be retrofitted to meet the needs. So the impact is to create dummy values to retrofit an object design to meet the primary requirement. So the answer to the question on whether the data structure needs of the requirement is a No because the solution has to retrofit the other 2 standard objects with predefined values to meet the needs.

Does the standard object meet the entity requirements for a legacy application, and what is the impact on data migration?

As part of our project, our legacy application had a data structure where they had individuals, with related addresses on another table. They also had a usecase where they shared addresses across individuals with a same address id. They had 3 tables namely individuals, individual address and address linked with the following relationship.

1. An individual has one to many addresses.
2. An address can have one to many individuals.
3. An individual should have a one to one relationship with Address.

On the Address object design for public sector, there is a master detailed object between location and address. To fit the requirement of an address shared with multiple individuals, we need to create custom fields with no uniqueness to meet the requirements. So this causes wrinkles in the design where we cannot enforce referential integrity on the object design in Salesforce, causing issues. So to answer the question on impact from a legacy application and data migration, the answer was No, and here was the thinking behind it.

1. Standard location and address object design does not meet the many-to-one relationship needs for addresses that need to be shared across individuals.
2. Leveraging location and associated location does not work with a junction object model that needs to meet the needs.

How does data access and security impact the decision on standard vs custom object design?

From our requirement , we need portal users to view addresses of all related individuals provided they had access to the person account. The internal user had an open access where they should be able to see all person accounts and related addresses easily. If we had used the standard address object model with all the location objects, we would need to do the following.

1. Create sharing rules on associated locations, locations and addresses to enable portal users to see all address data.
2. The master’s detailed relationship of location with address created wrinkles that prevented us from leveraging the inherited master’s detailed security model.

To answer the data access and security impact question, the answer for leveraging the standard object model is a NO because of the following.

1. Creating unnecessary sharing rules to share data from person account to address.
2. Mastering the detailed relationship of location with address can create issues with org-wide default sharing to future addresses.

How does a well-architected framework fit into the decision of standard and custom objects?

Finally if you look at the standard and custom object design using well architected(EAT), here is where you would end up on the decision.

From a well-architected framework, the standard object model did not fit the requirements.

To summarize, when you want to decide between standard and custom objects, here is a four-point question that will help you make a decision.

1. Will the standard object meet the data structure needs for your current application with respect to the relationship between entities?
2. Does the standard object meet the entity requirements for legacy application and what is the impact on data migration?
3. How does data access and security impact the decision on standard vs custom object design?
4. How does a well-architected framework fit into the decision of standard and custom objects?

To understand this in a framework, you should use the SWORD Framework to evaluate standard objects vs custom objects for your future needs.

If you have questions, feel free to post your comments and email me at buyan@eigenx.com for further questions.