Fields, Custom Settings, etc.
best practices, using APEX vs workflow vs formula fields, what type of field should you choose
Fields in salesforce come in all varieties of types and capabilities. Implementing them can increase or cripple an org depending on how you build your foundation fields. There are several important key facts to remember when building out fields in Salesforce
- Formula fields have character limits and can become too complicated with growing business logic
- Picklist (and multi-picklist) fields can use Global Picklists to increase data cleanliness and consistency
- Checkboxes should be rarely used, instead opt for picklists
- Large text areas are not searchable in reporting
Maintaining a clean understanding of these facts will help admins and developers build scalable, dynamic solutions. Developing efficient and clean APEX and workflow rules are dependent on remembering them. For example, when building out a product skew, it is best to implement a Global Picklist for the products to ensure the products are uniform across all objects in the org. The same is applicable for an "account segment" field or a "account type" field. When building out picklist fields maintaining a long term vision on where the field might be implemented is pivotal to ensure it's long-term success.
Formulas, while incredibly powerful, should be used sparingly. Instead, opt for building them out in APEX. When required to build a formulas, whether they are built in fields or workflow rules should always follow a format that includes comments for IDs and non-intuitive components. For example :
IF( AND(RecordTypeId="01234000000HqM3", /*Task Record Type*/ CreatedBy.Id="0053400000ALsMh"), /*Outreach Systems*/ Owner:User.Reporting_Role__c, IF( AND(RecordTypeId<>"01234000000HqM3", /*Task Record Type*/ CreatedBy.Id="0053400000ALsMh"), /*Outreach Systems*/ Alternate_AE__r.Reporting_Role__c, CreatedBy.Reporting_Role__c ) )
Following this format will streamline future development and provides a quick digest on the formula's logic without having to look up ID values. Implementing this format is difficult, but using tools such as ATOM and the Salesforce Enhance Formula Editor enable admins and developers to achieve these standards.
When building out checkbox fields, it is important to remember that multiple checkbox fields can be combined into a multi-picklist field. A multi-picklist field is a tremendous way to reduce a record's characteristics into one simple field. It can help increase APEX efficiency and reduce the field count on an object.
Custom settings are great tools to help establish org-wide defaults. They are great to help maintain data and permission consistency. Custom settings can be used in APEX as placeholder for environment variables or they can be used in batch APEX to dynamically change run criteria and conditions. The biggest pitfall of custom settings is the inability to deploy records between environments. All data created in one org for a particular custom setting cannot be deployed to another org.
Custom Metadata Types
Custom metadata types (CMTs) are the improved version of custom settings. Records in these components are deployable across environments, they are queryable, and have more available field types (including picklist values). There even is an option to create lookup relationships to other custom metadata type objects, creating a "related list" effect.
These features enable CMTs to be applied a wide variety of use cases. Trigger settings are a great place to implement CMTs. A CMT record, can hold a trigger description, active status, required components or run criteria, and can be sorted and grouped in native Salesforce views. These features and more enable non-developers to quickly check the status of a trigger or change a trigger's logic on the fly without addition change sets. Check out the Custom Metadata Type Resources for more detailed explanations on how to implement this process.
Other Tips & Tricks
- Create a custom setting for general variables such as a place holder for one million. This custom setting can be used in formula fields, APEX, workflow rules, and other components of the platform to reduce confusion of repetitive 0s.
APEX vs workflow vs formula
The debate between APEX, workflow rules, and formula fields is one with great implications for long-term scalability and dynamic adjustability. Formula fields are great for non-developers and provide a great solution for making quick changes to data across the entire org without having to run an update. While they are very dynamic and flexible in that aspect, they can become incredibly complicated and too long (there is a 5000 character count for all formula fields, inheritance is included). These restrictions can cause serious dilemmas as an org's business logic grows in complexity and size. Workflow rules are good alternatives to formula fields. But require significant documentation and record update in-order for the logic to process. Speaking from experience working at Procore, formula fields and workflow rules can help scale a small org to a medium org very quickly, but will cause significant problems scaling from medium to large/enterprise.
In place of formula fields and workflow rules, at Procore, we opted to start building APEX-based formula fields. The methods, stored in classes called Opportunity_Formulas and Account_Formulas, store all the business logic in the APEX code. They implement CMTs and constants that can be accessed in other parts of the code base. Another significant pitfall of formula fields is their place in the Order of Execution. They are calculated when the record is queried, which occurs in the after method. Formula fields are NOT accessible in before methods. Replacing formulas fields with APEX is beneficial because developers will be able to access those values in before triggers, which adds a tremendous amount of potential to the codebase.