Removing
Technical Debt

Salesforce Orgs can become unmanageably complex over time. This problem tends to be the most severe in the oldest and largest Salesforce Orgs.

Wooly Reports

Table of Contents

Introduction

Salesforce Orgs can become unmanageably complex over time. The complexity might stem from corporate mergers and acquisitions, poor change and release management practices, failed development projects, or disruptive administrative turnover. This problem tends to be the most severe in the oldest and largest Salesforce Orgs. Complexity can result in slow performance, reduced agility, sluggish adoption, and IT/business misalignment.

Consider an org where Profiles, Page Layouts, and Custom Objects are being created with the Setup Menu at a linear rate. The number of total user permissions in the org will increase at an exponential rate. But when you consider the impact of other entangled assets like Custom Fields, Record Types, Custom Tabs, and Apex Classes, the overall complexity of the org will increase at an even higher rate than in this simple example. Many Salesforce orgs become more complex every day.

This whitepaper discusses how to use Metazoa Snapshot to reduce the technical debt in your Salesforce org. Snapshot features comprehensive reports that show where technical debt resides in the org. Deleting unnecessary assets is a great first step in simplifying your org and reducing complexity. Once you understand where the problems are, you will be on the right track to reducing the complexity of your Salesforce org.

Discovering Complexity

To get a good sense of where the problems are, you should first get an asset count for each metadata type, followed by a comprehensive metadata snapshot of the org. Once an overview of all the org metadata is available, many problems will become apparent. Why are there 4000 inactive Assignment Rules? How did we end up with 7000 Groups? During this process, there will be business value judgments involved, not just technical issues.

For example, you might need to consider how the org should be structured to achieve corporate requirements. Snapshot has many reports can be assembled that help visualize complexity and understand where the bottlenecks are. These reports are also helpful for backup, compliance, and security. Compliance reports can be used on the front end to identify the problems and on the back end to document the changes to the org.

Here is a brief listing of Snapshot’s general purpose compliance reports that are focused on detecting technical debt. These reports can highlight specific problems for you. In many cases, you can also fix the problem without leaving the report interface. The Smart Deploy feature is discussed in more detail, below.

  • Full Snapshot– Capture all org Metadata into a permanent backup
  • Snapshot Limits File– Detain the number of assets by Metadata Type
  • Manage Time Series– Study how org Metadata has changed over time
  • Data Dictionary– Document all Custom Object and Field Properties
  • Org Dictionary– Document and Color Code any of the 250 Metadata Types
  • Impact Analysis– Discover how any asset is related to all other assets
  • Similar Assets– Discover Redundant Metadata in your Org
  • Relationship Matrix– Detail Asset Relationships in a Matrix
  • Fields Vs Page Layouts– Document Fields by Page Layout and Record Type
  • Record Types Vs Picklists- Document Picklists by Record Type
  • Controlling Vs Dependent Picklists– Document Controlling and Dependent Picklists

Unused Assets

There are several different metadata asset types that can end up being left behind because of org configuration settings. For example, maybe the asset is not referenced by any other asset. This can happen with Groups, Queues, and Email Templates. Perhaps the asset is not assigned to any user.

This can happen with Profiles, Permission Sets, and Roles. In addition, assets can be forgotten because they were deactivated or hidden. This can happen with Workflows, Assignment Rules, Approval Processes, and Flows. There are analogous problems on the data side, where Fields and Picklist Values can be underutilized. Reports and Dashboards can also go stale. Admins should take advantage of the compliance information that Salesforce provides for each Custom Field.

This information includes the Description, Help Text, Business Status, Security Classification, and Compliance Group. Special attention should be given to the date the asset was created and last modified, and which admins were involved. Deleting all these unused assets is a great first step towards org cleanup and optimization.

Snapshot has comprehensive reports that can discover and delete unused data and metadata. First off, the deployment toolset can be used to delete or restructure Metadata in production orgs and sandboxes.

The Data Migration tools can be used to remove or migrate data as well. In particular. the Forgotten Assets report has individual algorithms to detect over 100 forgotten Metadata asset types. These unused assets can also be deleted with Smart Deploy. Here is a list of the reports specifically focused on Deleting Unused Assets.

  • Field Usage– Discover and Delete unused Fields with Smart Deploy
  • Picklist Usage– Discover and remove unused Picklist Values
  • Forgotten Assets– Clean up over 100 Metadata Asset types with Smart Deploy
  • Last Activity Date- Clean up stale Reports, Dashboards, and Email Templates.

Field Usage

Some of the Custom Fields in your Salesforce account are more important than others. Some are rarely used, others not at all. Some may be forgotten, others are perhaps no longer required. One way to measure usefulness is to look at fields that are empty. Another technique is to look for fields and picklists that contain default values. Fields that do not appear on any Page Layout should also attract suspicion. Lastly, the SOQL API provides powerful grouping and filtering services that can measure how distinct field values are. The more distinct the field values, the more the field is being used, versus fields with more uniform values, which contain lots of duplicate information.

Once this information has been gathered, judgement is required on a field by field basis to determine their usefulness. You may need to drill down and see why a field is more or less distinct. For example, Account Name, Phone, and Website will be almost 100% distinct, but Account Zip Code and State will be more uniform. Often you will discover that more uniform fields are mainly populated by empty or default values. That might point to a field that needs to be deleted, or perhaps that should be a required field. If most of the fields are no longer needed, then the entire object can go.

Picklist Usage

The only thing more complex than fields are picklists. First off, picklists are multiplexed by Record Types, and further complicated by controlling versus dependent picklists. Picklists will have a defined list of values, but they will likely have many other values that have been entered by hand over the years. What values should be on the defined list? What other values need to be remapped to one of the defined values? Which picklist items should be eliminated from the list entirely? Once again, looking at distinct versus uniform values will give you lots of information about how your Org is using picklists and which ones require cleanup.

The Tooling API can be used to determine when a Custom Field or Picklist was created and last modified. You can also retrieve the Salesforce username of the administrator that made these changes. This information should be factored into any decisions about the importance of the field. Perhaps field usage is low because the field was recently created. Fields and Picklists that were created long ago and have not be modified should be looked at carefully and perhaps slated for deletion.

Forgotten Assets

There are over 200 asset types currently handled by the Metadata API. These metadata assets describe all the customizations in your org. But this information can also be used to discover forgotten, hidden, and inactive assets. In some cases, an asset will not be enabled by any of the Profiles or Permission Sets in the org. In other cases, there will be no metadata references to the asset. Many metadata assets have an “active” or “visible” flag that can be checked. The Data API can also be used to find assets that have no assigned users. Here is a list of common problems that can be discovered:

  • Groups not referenced by Custom Objects or Assignment Rules
  • Roles, Profiles, and Permission Sets with no assigned users
  • Custom Objects and Fields not referenced by other metadata assets
  • Record Types, Custom Tabs, and Custom Applications that are not visible
  • Web Links not referenced by Page Layouts or Home Page Components
  • Inactive Rules: Workflow, Approval, Assignment, Moderation, Escalation…

Stale Reports and Dashboards

Stale assets are properly connected to your Salesforce account, but they have not been used in a long time. Email Templates have a Times Used and Last Used Date field available from the Data API. Likewise, Reports have a Last Run Date. The Refresh Date for Dashboards can be calculated from the connected Reports. You will likely find Reports and Email Templates that have never been used, but be careful, because sometimes these objects are simply new, so be sure to also check the Created and Last Modified Dates.

Profiles

Every user has a Profile that defines what they can see and do. Profile permissions include Application and Tab Visibility, Apex Class and Page Access, Object and Field Permissions, User and Custom Permissions, and Layout Assignments. An administrator can also assign any number of Permission Sets to a user. Permission Sets are similar to Profiles. They are used to grant additional permissions for special situations. Profiles and Permission Sets are the key junction object that manage complexity at the heart of your Salesforce account.

The first thing to look at is which Profiles and Permission Sets are assigned to the most users. Perhaps some Profiles and Permission Sets can be consolidated. Another interesting report that can be generated with the Metadata API shows the extent to which various child types are used by each Profile or Permission Set. For example, which Profiles enable the most Apex Classes, or User Permissions? Which Profiles show the most Custom Tabs and Applications? This information will help identify duplicate and underutilized Profiles and Permission Sets that can be removed, refactored, and consolidated.

Snapshot has comprehensive resources that help you document Profiles, Permission Sets, and Permission Set Groups. You can bulk edit Profiles and Permission Sets when changes are needed. There is a capability to merge similar Profiles and Permission Sets. You can automatically create Permission Set Groups. Our Combined Security Report will show base Profile Permissions and how these are changed by additional Permission Sets and Permission Set Groups by User. Here is a concise list of Profile Management capabilities.

  • View Profiles– View and Bulk Edit profile Permissions with Smart Deploy
  • View Permission Sets– View and Bulk Edit Permission Sets with Smart Deploy
  • Field and Picklist Usage– Delete Unused Fields and Picklists with Smart Deploy
  • Combined Security Report– Document Profiles plus Permission Sets by User
  • Merge Similar Profiles– Discover and Merge Similar Profiles and reassign Users.
  • Create Permission Set Groups– Create Groups for Common Permission Assignments
  • User Permission Assignments–Rapidly Edit all Permission Assignments by User.
  • Profile and Deployment– Discover and Deploy individual Profile Permissions.

Permission Sets

Each assignment between a Permission Set and a User is stored as an internal record in Salesforce. These assignments control access to Objects, Fields, Apex Classes, etc. If there are many Users and many Permission Sets, then the total number of assignments can become very large. There can be great difficulty documenting the combined effect of all these permissions for an individual User.

Editing all these assignments through the Setup Menu can be tedious and error prone. When you assign Permission Sets toa Permission Set Group, there is a background process that calculates the new aggregate permissions for the group. This recalculation process can cause performance problems and delays in orgs with lots of active assignments. The best practices for resolving these issues include:

  • Evaluate combined Security Permissions by User
  • Identify and Merge similar Permission Sets
  • Reduce the number of assignments with permission Set Groups.

Permission Set Groups

A great new feature called Permission Set Groups will be included in the Spring 48 Version of Salesforce. Permission Set Groups allow any number of Permission Sets to be grouped together and assigned to a User. This new feature will allow enterprise customers to move away from monolithic Profiles and increase the adoption of Permission Sets, which are more agile and atomic. Permission Set Groups can be used to reduce org complexity and increase compliance and security.

Consider this illustration. Bob has been assigned the Marketing Profile. This profile only includes the basic permissions needed for any Marketing User. Other more specific permissions have been removed. Bob is a member of the Advertising Team, and so he has been assigned the Permission Set Group for Advertising. And by the way, Bob runs analytics for the Marketing department, so he has been assigned the Permission Set for Einstein Analytics to cover this special case.

What is really important about this diagram is that an Admin or Security Officer can look at the structure and see by inspection that Bob’s permissions are correct. The names and descriptions of the Profiles, Permission Set Groups, and Permission Sets are human readable. These names should flow from the corporate priorities for User roles and their top-down security design. The end result should be a permission architecture that emphasizes clarity, context, and meaning.

Inactive Users

Once a User is created, they can be made inactive, but they cannot be deleted. Over time, orgs can end up with more inactive users than active ones. There are over 50 different ways that an inactive user can remain connected to a Salesforce org. Inactive users can still manage active users, receive system emails, remain team members, and serve as the running user for Dashboards and other important enterprise systems.

These zombie users complicate org management and software development. They also pose multiple security threats. Tracking down and removing all the connections between inactive users and the Salesforce org can be a very complicated process. The connections can be by username, user email, and user ID. The best practice is to identify these Users and either delete their connections to the org or replace them with an active user.

Many other problems are related to Users. We once worked with a customer that had over 100,000 User Roles. When the Role hierarchy changes, this triggers a Record- Level Security recalculation. As you can imagine, this customer’s org suffered from massive performance issues due to constant security recalculations. In this case, the answer was cleaning up the Role hierarchy and then reassigning all Users to the correct Role.

The User Connection Cleanup report can document all 50 different User connections to the org. This report can clean up inactive users by deleting junction records and reassigning assets to an active User. This report can also reassign User relationships to data records.

The issues surrounding user management go beyond cleaning up inactive users. The License Expense Management report can be used to save money by identifying org, Package, Feature, and Permission Set Licenses with low usage. Handling users and their permissions correctly is mission critical for any Salesforce Org. Snapshot has a variety of Reports and Tools for User Management, including:

  • Lightning Security– Document and Edit all Record Pages in Lightning Experience
  • Record Level Security- Discover which Users can see which Records and why
  • Profiles and Permission Sets– Document the Combined Security Permissions by User
  • User Permission Assignments– Document and Rapidly Edit all Permission Assignments
  • Relationship Hierarchies– Document and Rapidly edit all User Role Assignments
  • User Connection Cleanup–Clean up all 50 different connections to Inactive Users
  • License Expense Management– Document and Edit User License Expense and Usage

Unlocked Packages

Unlocked Packages are a great new technology for reducing Org complexity. Unlocked Packages can be used by developer teams that are building new applications, and they can be used to convert legacy applications as well. There are many advantages to adopting Unlocked Packages. Bugs and problems are isolated to the package instead of being spread across the entire Org. When a project needs to be upgraded or replaced, the package makes entangled assets easier to identify. Packages are the foundation for agile development, enabling smaller groups of developers to focus on more isolated sections of code. Packages can be individually tested in a Scratch Org or developer account. Moving to Unlocked Packages can help lower cost, increase flexibility, reduce complexity, and improve time to production.

The great thing about managed packages is that they add an additional layer of separation with namespaces. Unmanaged packages can accomplish this as well with strong naming conventions. Each application sits in a separate silo, and this reduces Org complexity. Developing packaged applications is the wave of the future, but even the most advanced DevOps practice can’t succeed if the Org is saddled with technical debt. Here are Capabilities in Snapshot that will Help you move to Second Generation packages:

• Salesforce DX Support– Snapshot provides a graphical user interface for SFDX
• Create and Install Packages– Use your Dev Hub to migrate packages between Orgs
• Developer Packages– Store metadata assets on your local drive or online Repo
• Release Management- Deploy assets between Snapshots, projects and Repos.

Change and Release Management

So far, this blog has focused on techniques to identify assets that need to be cleaned up or optimized. After that, the best practices moving forward are:

  • Identify problematic assets that need to be cleaned up or optimized
  • Test what happens when these customizations are deleted in a Sandbox
  • Communicate to other users what customizations are being removed
  • Restrict access to the assets with user Profiles or by disabling the assets
  • Monitor the impact of the changes before actually deleting the assets
  • Decommission the assets with change and release management software

The adoption of an effective change and release management practice will ensure that your Salesforce org remains healthy. In fact, org cleanup and optimization should become a regular priority in the release cycle. This will ensure that your Salesforce org grows with new capabilities and robust user adoption but not with crippling complexity.

Conclusion

Salesforce has provided many powerful options for customizing an org and solving important business problems. But without proper management, a dynamic Salesforce org can become crippled with technical debt over time. But don’t worry! technical debt is a problem that can be fixed. Fortunately, the Metazoa Snapshot product can both find technical debt and fix the problems as well.

Companies can use the Salesforce Data, Metadata, and Tooling API to generate powerful reports that help you understand and visualize the complexity of your Salesforce org. Most Salesforce accounts get more complex every day. Cleanup and optimization should become a regular part of your change and release management practice. Our Snapshot product can create many of the reports described above and provides additional tools for Change and Release Management. Let us know if we can help you reduce the technical debt in your Salesforce account. Click the download button to get the pdf version of this whitepaper.