4 Salesforce Page Layout Design Principles I’ve Used for Years

I’m taking this blog in a different direction and am going to be generating a combination of Post and Video when appropriate. The intent is to have the video content reinforce the blog details. So, with that said, welcome to my first video/blog combo!

Over a decade or so of Salesforcing I’ve setup a few custom objects in my time. I’ve found that a well designed page layout makes adoption much easier for the end user and makes the data flow better when being consumed both in edit and read mode. They are super easy to implement so let’s get into it!


Move like fields together

When you think about the design of your object and how users are going to be interacting with it you should group like fields together. In our example, the Audit fields for Account/Contact lookup can group together because they are both lookup type fields but also because they may be updated in a subsequent save. In addition, the Status and Date fields can be grouped together because the business use case necessitates that both details would be known and/or change at the same time.

Require fields at the Page Layout Level

The distinction here on whether to require a field at the page layout level or at the field level is based on use case. If the end user will always, no matter what, be required to have the data then you can put the requirement at the field level which is the most restrictive. However, in our use case here the customer will not have perfect data when they import and will update the details as more information comes available. Therefore, we want to allow them to import and edit afterwards.

Large Text Areas get their own section

This principle is fairly straight forward, large text areas in two columns are ugly and in one column is pretty.

Hide or Move to the bottom all system fields

System fields often need to be referenced visually by the user on occasion so its good to include them on the page layout. One trick I use is to teach users how to collapse sections which makes navigation much easier. Its one of the Ah-Ha moment for users.

The Best Salesforce Swag I’ve Ever Received

Check it out! I bet you don’t have one of these. Let alone two.


A while back I had the great pleasure to run into a former colleague and boss of mine from my time at Salesforce Support. We got to talking about our favorite swag and I mentioned my Tie-Dye T-shirt. Long story short, there happen to be a box of them sitting just across from his desk. He sent me one and now I have two. You can tell, I really got some use out of my old one.

Despite being awesome, the Tie-Dye doesn’t make this my favorite piece of swag. Cread Hietakangas was a former colleague of mine at Salesforce Support who passed away several years ago. He was, simply put, an actual Salesforce Rock-star. No joke, the best.

I never told him this but I respected him and kinda hated him for how good he was at his job. Call it my youthful ignorance but its tough always playing second fiddle. Always being on the JV team. Sadly, I also never told him that he pushed me to make myself better every day. Being excellent at his job propelled me, in a some-what juvenile competitive way, to be better at mine. I wish I had told him that. The funny thing is, he still pushes me to be better.

It’s interesting how different people make profound impacts on your life. It might be odd to draw inspiration from a piece of Salesforce Swag, let alone a Salesforce T-shirt, but I do. Not because its Tie-Dye, which is awesome, as I’ve mentioned, but because ever time I see it I remember someone that was truly dedicated to being excellent at everything he did. That reminds me, in some little way, to strive to be excellent as well.

For what’s its worth now. Thank you Cread.

I guess what this post is really saying is, find your Excellence Muse. For me, its a Salesforce Tie-Dye T-shirt. What’s yours?

Hiring your next Salesforce Rockstar – Part 2 of 3

In part 1 I discussed how to define out your specific needs and to look for “My Rockstar” instead of just “A Rockstar”. This point is important to consider in our second part. The term Junior or Associate gets a bad wrap these days. I’ll admit, I’m a little bias myself when I see it. We think it means “No Experience”, “Average Performance”, “Not worth my time”, etc. This may not always be the case but I think everyone has run into this “junior” wall before.

If you’re reading this post you’re likely looking at hiring your first Salesforce Professional and that can be scary if you’ve never done it before or not sure what to look for. I’ll send you down two paths:

IF this is your first Salesforce hire then my suggestion is to hire someone with a bit of experience under their belt. Even a few years of working experience in the Salesforce ecosystem gives people a skill set that can’t be replicated in school or in other roles. For example, Admins with experience often know how to determine the right way to do something as opposed to the way you know how to do it. On the other end, you are likely to be inexperienced in working with an Admin and thus the relationship may not blossom as much as you hope.

There are some other options if you have never hired a Salesforce Admin before that will help you determine what you need and help define the skill sets you are likely to need in a resource.


There are several options to hire short and long term contractors on full-time, part-time, or even by project or ad-hoc basis. For example, Upwork.com has a large collection of Salesforce experts at a wide range of price ranges and expert levels.

Salesforce Partners and Consulting shops are also a good way to hire an Admin-As-A-Service type role.

Finally, link up with your local area’s User Group and ask for help. The User Group leader for your area usually has their finger on the pulse of who’s available and you get the bonus of getting a local person. Likewise, area businesses are almost always willing to share contacts of people they have worked with in the past.


IF you have hired some Salesforce professionals before and are familiar with your requirements for the position I implore you to think creatively and go “Junior”. As I mentioned before, this doesn’t have to be someone that is in-fact Junior but might be someone that doesn’t have a strict Salesforce background but has complimentary skill sets that enhance their value.

I’ll give you an example. I recently hired a Full-Stack Engineer out of a coding boot camp who was a career shifter from the banking industry. Their background is in ReactJS and they did several projects with this language in the coding boot camp they graduated from. I recently had a project handed to me to investigate Twilio Flex and the integration into Salesforce that integrates a softphone into Salesforce Service Cloud. Surprise, the front end of the softphone can be customized using… you guessed it, ReactJS.

You can learn Salesforce if you have a strong technical background. Salesforce Trailhead makes that easy. But its a little more difficult to go the other way and take a pure Salesforce Admin and teach them complimentary skill sets you might need. Exploring options in hiring “Junior” help to tackle this sort of need and gives you the freedom to train and mold a candidate.

Clean Up Poorly Formatted Data with RIGHT and LEFT Formula Functions

Poorly formatted data is a pain to deal with. In most cases, there isn’t much you can do about it. However, in some areas, such as URL’s, there is and we will explore an example of how to do this leveraging Salesforce’s RIGHT and LEFT formula functions.


Full credit for the inspiration for this post goes out to Sunil Sarilla, Salesforce MVP and Answers Community Champion.

Inspiration Post: https://success.salesforce.com/answers?feedtype=RECENT&criteria=BESTANSWERS#!/feedtype=SINGLE_QUESTION_DETAIL&dc=All&criteria=BESTANSWERS&id=9063A000000pVAsQAM

Poorly formatted data causes errors, lost time, and frustration among your users. However, validation rules aren’t always the best bet to force good data as you sometimes want to capture the data as it comes in such as in a web-to-lead form or via mass upload. Another good option is to have Process Builder or Workflow manage the data cleanup for you.

Take a look at an example of poor data; the Website field on the Account object is of DataType URL. But if this field has a strange character at the end … This doesn’t look like the quality of data we would like to have!


The Standard Website fields don’t have the same custom URL field validations on them and are essentially just text fields for all intents and purposes. This means that it accepts poorly or even incorrectly formatted URL’s. No matter how Awesome you are, bad data will always creep up on you and here’s one area where you can do something about it.

Suggested Solution:

Let’s design a Workflow Rule that detects similar data on that field and adjust it.

Here is a walkthrough:

1- Create a Workflow Rule on the account object and choose the Evaluation Criteria to be “created, and any time it’s created to subsequently meet criteria”.


2- Set the Rule Criteria as “formula evaluates to true”. Then add the following formula :



3- After saving, choose the Immediate Workflow Actions to be “New Field Update”


4- Add the Field Update, Choose the ‘Website’ field as the field to update and then add the formula that will correct the Data :

   Website, LEN(Website)-1


Finally, Save and activate the Workflow Rule. This will definitely prevent similar future errors. As you notice other invalid data to clean up you can add them to the criteria in the workflow rule. Likewise, you can use the RIGHT function to capture cleanup details on the right side of the URL. 

Denote Duplicate Records when Users Create them Manually

In this blog post, we explore the options to identify the duplicate record created when users are presented with the duplicate management warning message.

Full credit goes out to Tom Hoffman (https://success.salesforce.com/ProfileView?u=0053000000BgRsl) over at Accidental Admins (https://twitter.com/AccidentalAdmin) for the solution. I originally was sparked to write this post off of a Post I saw on the answers community – https://success.salesforce.com/answers?feedtype=RECENT&criteria=BESTANSWERS#!/feedtype=SINGLE_QUESTION_DETAIL&dc=All&criteria=BESTANSWERS&id=9063A000000E0OyQAK

I thought it was a neat solution so I wanted to explain it out step-by-step.


Business Requirement:

We definitely need to identify duplicate records created by users when they ignore the duplicate rule warning. Administrators need to know which is the duplicate record to merge them later as well as hone the duplicate management rules to improve duplicate rule performance.

Is there a way to stamp these records as DUPLICATE without apex?


Suggested Solution:

Designing a Process Builder that updates a number field on the duplicated record once created as an indicator. Here is a walkthrough :


1 – Create the number field on the object, set the default value to 0.


2 – Create a Process Builder on the DuplicateRecordItem object and evaluate when the record is created only.


3 – Set the Criteria; Choose the Condition field to be the Record ID from DuplicateRecordItem Object.


4 – Then, set the condition so that the Record ID starts with 003 (for contacts); check this link for ID prefix for each object.


5 – Add a field update for the field created in the first step; Let the value of the field be updated to “1”. Power of One – this will be helpful when you run a report especially if you want to know the number of duplicates in specific Accounts.




And… Now that you have read through this post completely here’s a small package you can install in your org if you don’t want to build the Process Builder and the Custom Field yourself. We have set this example up under Contacts as this is likely going to be the most common duplicate object we run into but the setup is the same for all objects.

Contact Duplication Identification: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t1E000001AX9L&isdtp=p1

Hiring your next Salesforce Rockstar – Part 1 of 3

Two points of housekeeping before I kick this blog post off.

  1. Sorry, it has been so long since I’ve last blogged. I have several excuses lined up and none of them really measure up to my personal commitment to this blog and that’s on me to fix.
  2. The below blog is my personal experience over the last few years of hiring Salesforce professionals and certainly isn’t an exhaustive list. Use this as one of several points of research.


I hate the term Rockstar. Its overused and I’m part of the problem. Rockstar implies that you are the best in your area of expertise, among the entire Salesforce ecosystem. I mean, come on, if everyone is a Rockstar then no one is. By definition, yes, there is A Rockstar out there. There has to be someone that is, indeed, “the best”. But you don’t need that person and here’s why:

  1. They are super expensive and would only produce marginally better products than, let’s say, the Rockstar Understudy
  2. Note the title of this blog is “Your Rockstar” not “A Rockstar” – Talent should be tailored as much as possible to your specific company and situation.

So, James, you ask with smitten how do I find “My Rockstar” then?

First, we must talk about Defining Your Need. I’ve made several mistakes over the years which have honed my skill set in defining what type of talent is needed.

Most Frequent Task

In this category, you define what you’ll be doing most frequently and then building a list of tasks that are likely to be the day-to-day tasks done most of the time. Then, match these tasks with skill sets needed. Are you writing and/or reviewing Apex code? Then you need development skill sets. Reviewing business requirements and generating customer stories? You need more business Analyst skills then. Here’s an actual example exercise I went through for one of our technical roles. This helped me realize that I didn’t need a Salesforce Admin skill set but rather more of a Developer/Business Analyst skill set.



Soft Skills

I can’t say enough about soft skills. I’ll expand this out to ancillary skills as well. Soft skills are skills that are hard to define with things like coding tests and certifications. Being able to work well within teams and communicate clearly to customers and internal resources are almost always needed. But there are several soft skills which you know you need and should always test. Often times these are honed from professional experience.

I’ll expand on ancillary skill sets for a moment. You may be an in a situation where you can’t find everything you want in candidates or are priced out of that kind of candidates. In that situation, you can look at ancillary skill sets to round out your skill set requirements. For example, if you need Apex/Visualforce experience but found a good candidate with Salesforce Admin experience and some JavaScript and HTML experience but no Apex/Visualforce experience. You can take a risk and this candidate and leverage Trailhead to help them learn the Salesforce side of things. If candidates have coding experience in similar languages or even Admin experience in similar CRM’s then learning the Salesforce side of things is exponentially easier.


Gut Check

There’s really no replacement for your gut feeling on candidates. Will they fit in with your company culture? Are they committed to your companies mission? Are they looking for the type of role you’re looking for or are they settling? These are important questions you need to ask yourself and be honest about your responses. In the end, its better for you and better for the candidate to be open and honest up front.




Designing Process Builder Criteria to Handle Record Types with Old Data

I haven’t blogged in forever… I have an excuse. Here she is:


My beautiful girl, Teagan Elizabeth Goerke

I had to give you all a good reason for being absent for so long. Now that the cute stuff is over, let’s get down to business. Process Builder business that is.

I recently ran into this scenario and you might run into it too. I’ll share how to fix it.

Business Scenario: Old records have no Record Type associated with them but more recent records do have a record type assigned

Error: Process fails with “The flow failed to access the value for [example] because it hasn’t been set or assigned.”

The more relevant error in our scenario is this:

Error element myDecision (FlowDecision).
The flow failed to access the value for myVariable_current.RecordType.Name because it hasn’t been set or assigned.

When records don’t have a record type assigned they technically do. It’s called the Master Record Type and each object gets one when it’s created, even standard objects. You just can’t see it. So, it’s odd that this error would come up with this scenario. I would expect it if we were working with a lookup variable that wasn’t required. But I didn’t expect it for Record Type. But it seems Process Builder can’t see the Master Record Type either. Bummer.

We have two fixes:

  1. Update all our records with a Record Type – Somewhat impractical for some situations
  2. Design our Process Builder to work with blank Record Types – Much more practical

I’ll focus on #2.

You should read this article as it describes the fix: https://help.salesforce.com/articleView?id=Process-fails-with-The-flow-failed-to-access-the-value-for-example-because-it-hasn-t-been-set-or-assigned&language=en_US&type=1

But here’s a walk through:

Screenshot - 8_26_2017 , 7_25_16 AM

No Record Type

Now our Process

In our first design we only accommodate for the Record Type:

Screenshot - 8_26_2017 , 7_29_19 AM.png

But this design will cause errors for blank record types.

A better design is to first check for a blank record type as well as a specific record type. Like this:

Screenshot - 8_26_2017 , 7_32_41 AM

It’s important to note that you should always put the blank Record Type criteria step as always before any additional Record Type criteria evaluation against other values. It doesn’t have to absolutely be first but it needs to be before all the other Record Type references.

As a best practice from a Design perspective, if your Object contains records with blank Record Types then you should build your Processes to accommodate those records or your users will get errors and no one likes flow errors.