Understand usage of fields in an object using field trip

In a huge organization where we have many custom and standard objects and when we create various fields as per the requirements, there are chances that we end up creating multiple fields and at times might not be using those fields as needed or there may be instances where in we end up the Salesforce limit of field creation per object i.e. 1000 and then we have to look out for options which fields can we delete to accommodate new fields.Eliminating unnecessary fields will help with user adoption and efficiency and makes your org clean. So how can we achieve this i.e. underutilized fields?

We have an application called as Field trip that does this job for us, we have to install this manage package and this app gives us a very clear picture of the percentage utilization of fields across all the objects whether its standard object or custom object. This app can be downloaded from an App exchange for free!!!!

Field Trip lets you analyze the fields of any object, giving you instant insight into what percentage of your records (or a subset) have that specific field populated. Run reports on the standard and custom fields you have in Salesforce for a better understanding of which field are important to your organization.

With a simple install, an intuitive user interface, and an easy-to-export report, Field Trip has made analyzing your fields quick and painless.

Once installed, simply name your trip, select an object (e.g. Accounts) and, optionally add a filter (for record subsets). Then you will receive a report detailing field usage (or lack thereof), available for simple export.

For more details visit : https://appexchange.salesforce.com/listingDetail?listingId=a0N30000003HSXEEA4

Using this link you can download this app for your org and check for the utilization of fields in an object.

Understand your code for a new org

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.

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?

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.

Understand configuration of your new org/Salesforce Optimizer

When you are assigned a new project, it is not easy to understand the use case for all.

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
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?

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.

Understand your code for a new org