Skip to content
Menu
Kymes.blog
  • Blog
  • Contact
Kymes.blog

Processes, Page Layouts, and Record Types

Posted on 08/25/202508/25/2025

This is the article that I was sure I’d write but I thought it wouldn’t be a for a few more “cycles”.  

Getting my bearings back 

After correcting my previous user/record security error, updating field access to the Vehicle ID# field on the Service Request object for the Front Desk profile, and enabling the correct listviews for all profiles I was ready to move on to the next step I originally planned. 

The plan was to build-out a custom business process. Because the CRM involved two custom objects, I couldn’t use the pre-built business processes used for standard objects. 

All the elements taken together to build a business process infrastructure involved page layouts, and record types, along with a picklist to attach to the path element added into the page layout. 

Getting started 

For the page layouts, I wanted a layout for each object for the Front Desk profile user, and a separate layout for the Mechanic profile user, each with their own “particulars”. 

For the Vehicle object layout, I updated the highlight panel at the top of the page and separated the related list and Record Detail tab, with the Record Details staying on the left side of the screen and the Related list showing related records from the Service Request object showing on the right. 

For the Service Request object page layout, I wanted to build a general, generic layout because I would need to assign it to two record types and make further customizations. 

I added a Highlights panel to the top, added a path element (picklist added later), removed the related tab on the left (field value showed Vehicle ID # for the Front Desk profile only and I didn’t see a reason for a related list) leaving only the Record Detail tab, and kept the Actions elements on the right. 

Fixing a small error: 

For the next step I knew I needed to build a picklist to attach to the path element, but first-things-first, I had to enable the path element. After enabling the path element, I build out the Vehicle Status picklist and connected it to the path element. 

After checking the two profiles view of the page layouts, I discovered that the path element wasn’t showing up.   

After a quick settings check. I discovered that there were two record types attached to the two user profiles (may have been from the previous troubleshooting that I forgot to catalog). Finding a solution started as an exercise in patience. 

I tried to delete the record types but couldn’t because they needed to be deactivated, tried to deactivate but couldn’t because they were defaulted.  

Eventually I worked out the solution, I went to: 

Setup > Users > Profile > Object Settings > and went to “Record Type and Page Layout Assignments” and assigned the Master record type to the user profiles. Next, I navigated to: 

Object Manager > Service Request {object} > Record Types and deactivated /deleted the other record types so all users were on the Master record type. All profiles could see the Path element on the Service Request object at that point. But I still needed to set up Record Types. 

Figuring out Record Types: 

For the record types, I knew I only needed to set them up on the Service Request object and connect them to the Vehicle Maintenance multi-select picklist field. I eventually settled on two record types, one for scheduled maintenance and another for more rigorous repair jobs.  

I built the first Vehicle Maintenance record type and connected it to the Vehicle Maintenance fields involving routine maintenance like fluid checks, filter checks, and tire maintenance. The second record type picklist values involved more serious repairs like engine and transmission maintenance. 

I also created a Vehicle Status picklist field to attach to the Path element. Because it is crucial that the Mechanic have edit access to update this picklist when looking at Service Request records, I went to: 

Home > Profile > “Mechanic” > Object Settings > “Service Requests” and enabled “edit” under Object Permissions and verified that both read and edit access were checked in Field Permissions. 

Page Layouts and updates:  

Up until now, I’ve kept the page layouts simple and standard. I’ve connected the same layout to both record types on the Service Request object with the Vehicle status picklist values attached to the path element. I’ve also created another page layout for the Vehicle object just to establish the infrastructure for further customizations (next step).  

For the layouts, I wanted to clean up the page. They needed to be cosmetically distinct so the user wouldn’t have an issue knowing which page they are on. 

First, I wanted to set up Compact Layouts to show at the top of the page, I went to:  

Object Manager > Vehicle > Compact Layouts > New 

For the Vehicle object I added Name as the top field, I then added Email, and Phone Number to the record page and changed the Primary Compact Layout to the Vehicle layout. 

For the Service Request object, I set the record type as the first field on the Compact Layout so that the user will be able to see the type of record they are looking at immediately. I followed those with Name, Email, and Phone Number.  

Next, I wanted to make sure that the Search Layouts were current so when a user is hovering their mouse over the related Service Request record link on the Vehicle object, they won’t have to leave the Vehicle record page to see relevant information.  

I went to Object Manager > Service Requests {object} > Search Layouts. I then mirrored the Compact Layout where I included the record type first, followed by Name, Email, and Phone Number. 

Closing:  

Originally, I saw this as a project to get a sense of where I am regarding using the Salesforce platform. Through this project, I’ve explored the synergy among Profiles, Picklists, and Record Types which resulted in (my opinion) a solid foundation for further customizations. 

In a previous article, I stated that Objects, Field, and Relationships was too limiting, and I still feel that is accurate as further updates will be largely incremental and not relationship based (unless I wanted to build something based around marketing). 

I do have ideas for other applications, but because I built this CRM on a generic sandbox, I’ll be rebuilding the CRM on a Developer org next. I’m using that to refine my process and will post an outline of the steps I took to complete the rebuild. 

If you are interested in a demo of the CRM please don’t hesitate to schedule some time on the Calendly link on my About Me page.

©2026 Kymes.blog | Powered by SuperbThemes!