Establishing and maintaining standards are important in a Salesforce org. They determine the basic rules of an implementation, so it doesn’t look like it was built by 3 admins and 2 devs.
Here are three core ingredients to build standards in a Salesforce CoE:
1. Naming Standards
Sample questions to ask yourself are:
- How should custom objects and fields be named? (see below)
- How should flow variables be named? (e.g. “Count” or “varCount”?)
- What should the API name be when there’s a number? (e.g. “Order #” or “Order Num”)
- How should validation rules be worded? (e.g. “There is an error” vs “The field ‘Account Type’ is mandatory”)
In regards to labels, UX principles recommend using a front-loaded system. This means placing the most important and differentiating word first. For example, call the custom field “Acknowledgment Status”, not “Status of Acknowledgment” and Anniversary Date”, not “Date of Anniversary”.
2. Coding Standards
There are dozens of best practices when it comes to apex coding, but to name a few
- Bulkify your code
- Using collections, streamlining queries, and efficient for loops
- Streamlining multiple triggers on the same object, follow the rule for one trigger per object
- Use of the limits apex methods to avoid hitting governor limits
- Use @future appropriately
- Avoid hardcoding Ids
The goal here is to be modular and scalable.
3. Decision Trees
Creating a decision tree will help address future problems, the known unknowns. For example, if you need an integration, based on the volume of data, the need for speed (real-time vs batch), and the type of data, such as Personal Identifiable Information (PII), will determine which integration pattern to use.
Creating a tree of yes/no questions would help make that determination. This step also needs to involve an integration architect.
The takeaway
This mail was designed to simply introduce the concept of standards. Each of these topics could span multiple emails, and I’ll definitely revisit them further at some point.
The key point is, although you may be designing, implementing, and supporting a Salesforce org today, it doesn’t mean you’ll do it forever. Having standards makes it easier for onboarding new team members and for future Salesforce partners taking over where you left off.