Examine SF Code & Declarative Processes
Source Trailhead
| Type of Code | What to look for | Questions to ask |
| Triggers | 1. Trigger patterns 2. Trigger logic | Does your org have one trigger per object? Is there business or application logic written directly in a trigger? Do triggers “hand off” logic or functionality to other classes (aka trigger handlers)? |
| Apex Classes | 1. Naming conventions 2. Comments 3. API Version | Do Apex classes use common prefixes or even namespaces to group units of code? Do classes have similar names, based on functionality? Is the purpose and authorship of code documented in comments? Do classes have comments that help clarify function? What API versions do classes use? |
| Apex Tests | 1. Test patterns/units 2. Code coverage 3. Test data handling | How do tests relate to other code? Does each class have its own test? Are your tests organized into functional groups? Are there parts of your code base not covered by tests? Do your tests depend on common data factories or static resources? Do any of your tests use the ‘seeAllData=True’ annotation, or run on an API version earlier than 24? |
| Lightning Components and Events | 1. Naming conventions 2. Comments 3. Apex controllers 4. API Version | Do components use common prefixes or even namespaces to create groups? Do components have clear names, related to functionality? Are Lightning events scoped to be application events or component events? Are the purpose and authorship of components and events clearly documented in comments or Aura documentation files? Do components use Apex controllers? What API versions do components and events use? |
| Visualforce | 1. Naming conventions 2. Comments 3. Apex controllers 4. API Version | Do Visualforce pages and components use common prefixes or even namespaces to create groups? Do pages have clear names, related to functionality? Do pages use Apex controllers? What API versions do pages use? Are pages used with any email templates? |
Examine Processes and Declarative Customization
| Type of Customization | What to look for | Questions to ask |
| Process Builder | 1.Object-related patterns 2. Active/inactive versions 3. Process logic | How many processes exist per object? Are processes clearly named? How many inactive versions exist per process? Do decision nodes have clear logic? Are commonly used actions grouped into invocable processes? |
| Workflow Rules | 1. Object-related patterns 2. Active/inactive rules 3. Action logic | How many workflow rules do objects have? Are some objects busier? Are rules clearly named, with descriptions? How many active and inactive rules exist on objects? What kinds of actions do rules execute? Do rules carry out any cross-object field updates? |
| Flow/Visual Flow | 1. Naming conventions 2. Object-related patterns 3. Active/inactive versions 4. Flow logic 5. Flow screens | Do flows use prefixes or similar names to create groups? Do flows have names clearly related to functionality? Do flows have clear, up-to-date descriptions? What object(s) does a flow interact with? What is the relationship between inactive flows or flow versions and active flows? Do flows put common functionality into subflows, invocable actions or quick actions? If flows have screens, are they based on Lightning components? Do screens depend on certain objects and fields? |
| Objects and Fields | 1. Naming conventions 2. Record types 3. Page layouts 4. Permissions 5. Action overrides | Were custom objects created that duplicate standard object behavior? Do multiple business units use the same objects or fields? Are business logic and validations differentiated by record types? Do objects and fields have clear, up-to-date descriptions? |