Looking back at Salesforce instances developed 5 to 10 years ago, we see companies struggling to overcome foundational issues. 

Many Salesforce.com systems began in their infancy as a system to target a sales team, a service organization, or a single business challenge. With simple configuration, proper end-user training, robust reporting, and accountability, those goals were successfully attained. Whispers of the beautiful solution start to emerge and trickle down to more parts of the business. Other teams see the potential for the system to solve their challenges as well.  

With each business solution implemented, the system becomes more complex. Each project brings the possibility of technical debt. It might not be until years down the road, but it can lead to end-user confusion, strained development resources, and executive-level frustrations. Reducing technical debt can seem like a huge mountain to climb, but taking a step back can mean many steps forward.  

Projects that are focused on tackling technical debt take time and analysis. 

In larger organizations, this can seem impossible. Buy-in and a strategic approach combined with tactical execution are essential for success. Success would mean a more efficient system; more projects could be tackled because the roadblocks slowing down development have been removed.  

A few essential elements: 

• Management needs to advocate for the current project and ensure adequate resources are allotted.  
• Subject Matter Experts (SMEs) should be identified to answer questions during the analysis process.  

WARNING: Technical debt reduction projects can be an easy target to be sidelined for other new projects that have a higher level of executive support. A sidelined project could mean starting the recommended steps over again. Executive buy-in support is key.  

The Customer 360 view has been a hot topic as of late. Record type/page layout consolidation is an essential piece to achieving this. While record type consolidation can be a heavy lift, starting with page layout gets you one step closer. This article tackles environments with many different page layouts across record types & profiles.  

Page Layout Technical Debt: 

• Do the users have issues finding fields because each layout has the information in a different location on the page for different record types? 
• Are users missing information because the field in question was not placed on the page layout? This also would have an impact on data accuracy. A user cannot enter/update data that is not visible to them on a page layout. 
• Do the page layouts look unkempt because new fields have been dropped to the page layout during field creation and not placed in the appropriate section?  

Solution 

• Decide which object to tackle first.  

• • Where do you see the most impact on the customer and end-user?  
  • Will the existing technical debt cause headwinds on current development projects? 
  • Meet with SMEs to identify their pain points and engage them in the overall project.  

• Analyze the existing page layouts. 

• • Is there a page layout utilized by most of the users? Could this be your master layout to start with?  
  • Identify common fields across all page layouts. 
  • Identify required fields/read-only fields as determined by the page layouts. 

• Assemble new/streamlined page layouts.  

• • Identify key fields in the processes. 

• • Categorize fields into field groupings, then place them in sections. 

• Review with Business & End Users 

Step 1: Decide which object to tackle first. 

This seems straightforward, but it depends on where your customization and complexity exist.  Look at the processes that directly impact customer service or are deemed a critical part of the business. Try to tackle those first.

Step 2: Analyze the existing page layouts. Identify/understand the users’ view of the record. Reporting can help to achieve this. 

• Record Type Analysis 

• • Which record types are used most frequently on this object? What profiles do the owners of the records fall under? If it makes sense, limit the time filter to the last 2 or 3 years. Each object will be different based on how frequently new records are added to the system. 
  • Which page layouts are associated with the profiles/record types that are used most frequently? Some SME feedback will be needed as this can typically extend beyond the ownership of the record. Example: customer service might have a heavy reliance on the data and should be considered as a primary or secondary profile. 
  • Document the Record Type / Profile /Page layout matrix. Understanding the Active Users that belong to each profile might be beneficial. That could help to place a weight on the user impact of these changes. Identify a Primary and Secondary page layout per record type based on the data above.  

• Identify common fields across all page layouts.  

• • For basic systems with a limited number of fields, this might be able to be compared by viewing page layouts side by side.  
  • When there is a plethora of fields involved doing data analysis is always a great place to get started. For a recent client project, we utilized a tool called FieldPro, which provides analysis of the object, and utilizing standard salesforce reporting produced the data we needed. Goal: Understand which fields are currently associated with the Page Layout association. Run and pull the report on all records. With some simple excel formula work, the field level page layout level association is clear. 
  • Field Usage Analysis (Optional): Utilize Fieldpro to identify unused fields. These could be from older processes or from data that was never populated—limit data to those records created in the last 2 or 3 years. 
  • Security Assessment – Unfortunately, this can only be done by visually analyzing the page layouts and documenting the read-only and required field page layout settings. Discuss these with SME.  

Step 3: Assemble new/streamlined page layouts.  

• Determine a master page layout(s). Keep in mind that our goal is to reduce page layout(s).  

• • Record Type Analysis: Utilize the information when you determine the primary and secondary page layout. 
  • Field Level Analysis: Do any page layouts contain 70-80% of the same fields? These would be a prime target for page layout consideration. 
  • Visual Analysis: Are there some layouts that are visually more appealing to users? Are there page layouts where sections are clearly defined, and the field groupings make sense? Are related lists prioritized based on functional use? 

• • Data Entry: Simulate the user experience. Are the required fields near the top of the page? After creation, does the field placement of formula, roll-up summary fields, and read-only fields make sense? 

• Begin to build your page layout 

• • Clone the applicable page layout(s) and adjust the fields per the previous analysis.  
  • Review the information you used in the data analysis step.  Look at this information holistically instead of primary/secondary. It is important to be able to show data for fields you might have removed.  
  • Field Placement: Utilize page layout best practices to ensure the best user experiences—some recommendations.  

• • • Place the required fields early in the tab order when possible. 
    • Place read-only, formula, and roll-up summaries on the right-hand side of the page.  
    • Rich text fields should be placed at the bottom of the section or within their own one-column section. 
    • Adjust related list order, so more utilized lists are towards the top of this area. 
    • Associate new page layouts to profile & record type in the sandbox. 

• Field Permission (Page Layout) Security  

• • Option 1: A shift to validation rules might be necessary to replace these customizations. 
  • Option 2: While our goal is to reduce the total number of page layouts to provide that customer 360 view, it might be necessary to consolidate down to 2 or 3 to provide the required/read-only page layout settings. 

Step 4: Review with the business.

• Have a working session with the SMEs for the page layouts that you are combining. One for each new page layout. As a team, they need to decide which field placement will make the most sense. Doing this together will create stronger adoption. 
• Identify UAT users – allow them to test and provide feedback before moving these new page layouts into production. Adoption of these page layouts is important to reducing the technical debt.  

Deployment Tip:  

• Prior to deployment into production, create a dev sandbox. This produces a backup copy of your instance that can be used to restore both the page layout and the assignments. 

Unfortunately, there is no magical button to reduce technical debt. These steps will help companies get started, but the project must be backed with the resources to see the work to the finish line. Trying to do this and manage an already full workload will be impossible for the technical resource. A consultant could help you manage this harmonization project. They can provide the outsider’s perspective to drive the conversation of change. Reach out to Zinc Partners today for assistance.