The Power and Peril of Salesforce Data Architecture

Salesforce automatically and instantly creates user experiences for staff, customers and partners based on how you configure the data model hence it is critical to get this right. This is the foundation upon which your user experiences are based so keep it clean, consistent and well-constructed.

Why is Data Architecture Important?

I don’t often see people describe Salesforce as a “code generator” but one of the Salesforce platform’s key strengths is how it automatically creates user experiences for staff, customers and partners based on a configured data model.

As objects are added to the database Salesforce instantly makes these available for data entry in the Classic and Lightning Experience user interfaces. Data model changes also appear instantly in communities exposed to customers and partners. And data model changes also appear instantly in APIs exposed to external systems.

The ability to add or change a database schema and have that alter a user experience is the role of a “code generator” in other software development environments. But with Salesforce you don’t see this step as changes to the data model are reflected instantly across all channels. Power.

Changes to the Salesforce data model can be made directly in production. Peril.

The ability to auto-magically and instantly generate new user experiences as changes are made to the data model is the core power of the Salesforce platform.

It is also the platform’s core weakness if those changes are made without discipline or regard for data architecture best practice. Especially if made directly in production.

Salesforce Data Architecture and Management Designer Certificate

Salesforce have an architect credential available “designed for those who assess the architecture environment and requirements and design sound, scaleable, and high-performing solutions on the Force.com platform as it pertains to enterprise data management”.

I believe Data Architecture and Management Designer is the most important of the six architect designer credentials.

If the data model is messed up it won’t matter how good everything else is.

It’s a shame Salesforce allow people to earn the “Certified System Architect” credential without earning the Data Architecture and Management Designer Certificate. I advised Salesforce to change the Salesforce Architect Journey so candidates had to achieve the Salesforce Application Architect credential before proceeding to the Certified System Architect credential.

See http://certification.salesforce.com/dataarchitect for more details.

What Typically Goes Wrong?

I most often see these issues:

  • Database objects and fields added directly in production bypassing any measured approach to impact assessment and testing
  • Database fields configured in an inconsistent way so the user experience also becomes inconsistent
  • Database fields configured without regard to data quality by choosing the most appropriate data type and applying validation rules
  • Database fields added with duplicate names leading to uncertainty about which field is which when doing data entry or building reports and list views
  • Database objects configured within the native Salesforce data store without regard to large data volume impacts and without considering alternatives like Big Objects or External Objects
  • Database objects inter-connected with relationship fields which don’t reflect the reality of business context, like not being required when they should be
  • Database picklist fields with ambiguous values and not being based on a restricted list
  • Data not restricted to a common data entry format using validation rules
  • Existing data not being cleaned up when rules are tightened leaving records in an invalid state
  • User adoption goes down in parallel with a growing distrust in the data

How to Leverage the Salesforce Power without feeling the Salesforce Pain

All Salesforce customers should develop clear guidelines about what sort of changes can be made to the Salesforce data model directly within their production environment.

  1. Here are some rules I like to see in place
  2. Never install applications directly in production
  3. Never add new custom objects or new custom relationship fields directly in production
  4. Be consistent with data field type selection so all fields similar in use or purpose are configured the same way
  5. Never have two fields in the same object sharing the same label
  6. Add help text to all custom fields
  7. Define picklist values so only one makes logical sense to select at any point in time
  8. Avoid putting large data volumes into an object without assessing the impact and options
  9. Ensure those making data model changes have completed the Data Modelling, Data Management and Data Security Trailhead Modules which are in the Developer Beginner Trail https://trailhead.salesforce.com/en/trails/force_com_dev_beginner
  10. In larger enterprise sized environments engage or hire someone who has passed the Salesforce Data Architecture and Management Designer Certificate

About the Author

Richard Clarke is a Salesforce Practice Manager and Technical Architect within Artisan Consulting’s Salesforce Delivery Team. Richard has led Salesforce delivery teams in the Australia, New Zealand and the USA and applies over 20 years of enterprise software experience when delivering business value with Salesforce.com.

Richard holds over 20 Salesforce certificates – including the Data Architecture and Management Designer Certificate

 


Leave a Reply

Your email address will not be published. Required fields are marked *