Take Stock of Your Org's Customizations
Learning Objectives
After completing this unit, you’ll be able to:
- Identify the business and tech value of current state assessment.
- Identify what to look for in a code base.
- Identify how to examine processes and declarative customization.
In a piece titled Reason in Common Sense, the poet and philosopher George Santayana wrote: “Those who cannot remember the past are condemned to repeat it.” The same can be said of teams who build apps. Taking the time to identify what’s been built in your org—and why it got built, and what standards were used as it got built—sets you up for future success.
Starting adoption efforts by looking at the current state of your org lets you clearly identify problems before you begin to make changes. For example, identifying technical debt—those implementation decisions that made sense early on but are preventing innovation now. You can also find opportunities to better engage with the right stakeholders and make adjustments to your teams before processes are too far along.
Looking at the way you’ve been working before you begin changing it has a lot of the same benefits for your technology and app delivery teams. It also can give you an opportunity to identify what problems or frustrations in your current systems are created by outdated tools or technology—and what problems come from human issues. These human-based problems are the ones you really need to address before trying to adopt any new technology or functionality.
So how do you start examining your org as it stands today?
Examine Your Code
Examining your code base can seem daunting. Especially if you’re new to an org or if your org has lots of code. But understanding how the different pieces of your org relate to one another is an essential, necessary part of identifying how to begin managing your org in more precise, meaningful units.
So what do you look for in your code?
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 factors 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? |
These pieces help you identify patterns within the code in your org. But these techniques may not help you understand every piece of your code base. Or, if your code base doesn’t seem to be consistently organized, you may need to try other ways to discover how your org’s code is connected.
This is where the new Dependency API can help. By running new kinds of queries, you can identify how your code and metadata are organized. You can, for example, look at a Lightning component on a particular page, or the Apex controller of a particular Visualforce page, and trace back all the other pieces of metadata that somehow connect to that Apex controller or Lightning component. You can also use these queries to identify pieces of metadata that are no longer in use and decide if they’re safe to delete.
Examine Your Processes and Declarative Customization
So what about the declarative customizations you’ve carried out in your org? How can you start looking at things you’ve built with clicks and not with code?
One way to get started is to use the Salesforce Optimizer. This tool can recommend ways to improve some of the features in your Salesforce implementation. After you’ve looked at your Optimizer report, you can look more deeply into your org’s processes and declarative customizations.
So what should you look for?
Type of Customization | What to look for | Questions to ask |
|---|---|---|
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? Are there any out-dated automations that need to be turned into flows? |
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? |
You want to create a clear sense of how well organized your processes and declarative customizations have been to date. If you find that your org isn’t as organized as you’d like, that’s OK. Now is the time to identify places where your team can work to increase quality and develop some standards that can help you build a healthier org moving forward. You may also identify projects that you want to tackle first, to clean up pieces of your org.
Stay Tuned
We’ll be adding more resources and opportunities to get hands-on with these concepts in the coming months. You’ll have the ability to explore untangling metadata and create packages, and learn more about managing unlocked packages.
Resources
- BA Times Article: What About the Current State?
- Atlassian Article: Escaping the black hole of technical debt
- Blog Post: Paying Down Your Technical Debt
- Salesforce Help: Which Features Does Optimizer Evaluate?