Record Types: A Better Way to Handle Varied Business Processes

Record types play a key role in Salesforce implementation. Without having a good understanding of them, developers or architects may end up devising an incorrect solution or writing code, which may turn out to be a suboptimal solution.

Now there are various ways to meet this requirement. For example, we can write validation rules that state that whenever the value in the Industry field is Manufacturing, make the three other fields required. This requires users to populate the fields before they can save the record.

Even if the validation rule works, it will create a negative user experience because the required fields, as a result of the value Manufacturing in the Industry field, would not have red asterisk attached to it.

Figure 5-1 demonstrates how developers can make fields required based on the value in the Industry field . The aforementioned approach (Figure 5-1) has the following issues:

1. 1.

   Right off the bat, it creates a negative user experience because the required fields (only when the value in the Industry field is Manufacturing) would not display a red asterisk next to it!

    
2. 2.

   Second, what happens if users select a value other than Manufacturing in the Industry field? In such a scenario, they would be able to skip entering the data in the aforementioned required fields because the validation rule would not trigger if the value in the Industry field is anything other than Manufacturing. This situation creates a big dent in achieving, and maintaining, data integrity—to say the least!

   To avoid a negative user experience or avoid compromising data integrity, developers and architects have to write a complex validation rule.

    
3. 3.

   The validation rule route displays unnecessary fields on a page layout when a value other than Manufacturing is in the Industry field. In such a scenario, fields like Annual Income, Date of Birth, or Shift Hours would gobble up page layout real estate without adding any value—not to mention delivering a suboptimal user experience.

    
4. 4.

   Last but not least, with the validation rules route, confusion, a negative user experience, and clutter in the page layout skyrockets if developers or architects are tasked with adding a few custom buttons or links to the page layout specific to the manufacturing industry!

    

Still not convinced the validation rules route may be a suboptimal solution? Well then, let us take a look at another example.

Assume the marketing director is happy with the validation rules solution you provided, and that it works as of today. However, the director now walks into your office and tasks you with a new requirement: she wants the value in the Industry field to be Shipping. When the value in the Industry field is Shipping, you need to create more than 40 fields. The marketing director also wants to gather additional data, such as participants’ current job duties and bonuses, when the value is Shipping. To avoid confusion, a negative user experience, and clutter in the page layout, the director does not want the 40 fields to be displayed if the value in the Industry field is not Shipping.

In light of this situation, do you still think the validation rules route is an optimal solution? I don’t think so either. To conclude, because page layout doesn’t allow users to show/hide fields based on the value of another field, the validation rules route falls short. Developing a solution for the various scenarios just described requires developers and architects to use record types as an option.

What Are Record Types?

Record types allow you to group similar fields and display them to users as necessary. They do so by enabling you to segment a particular object’s fields/sections for specific uses.

Figure 5-2 demonstrates how a page layout is organized in different sections. Think of the Opportunity page layout as a large box that contains multiple compartments. The same page is displayed to all sales reps at every stage of a deal, regardless of whether the sales reps have use for all the fields on the page layout. As we saw earlier, this affects productivity and the sales reps’ experience negatively.

Record types to rescue! Record types help improve the sales rep experience by displaying appropriate sections/fields on a page layout based on an Opportunity stage .

Record types are used mainly for two purposes:

1. 1.

   To show different page layouts based on conditions. For example, if an Opportunity stage is Closed Won or Closed Lost, then, display the Read Only page layout.

    
2. 2.
   To show/hide picklist values. For example, if an Opportunity type is Existing business, then remove the following values from the Lead Source field:

   • Partner

   • Employee Referral

   • Other

    

As a developer, you can create three different page layouts—Discovery, Billing, and Shipping—then display different fields on the page layout based on the value in the Opportunity stage field.

Table 5-2 represents the page layouts and their dependency based on the Opportunity stage. To control fields in page layouts based on the Opportunity stage, you need to use a record type.

Table 5-2

Page Layouts and Their Dependency on the Opportunity Stage

Page Layout	Stage
Discovery	Prospecting
Billing	Proposal/Price Quote
Shipping	Closed Won

Figure 5-3 demonstrates how record types control page layouts based on different stages. One record type can assign different page layouts to different profiles, or one record type can assign a single page layout to multiple profiles. In Figure 5-3, record type controls discovery page layouts 1 and 2 based on the profiles. So far so good. Let’s take this discussion one level up.

Let’s get back to our business scenario with Robin Guzman. He’s received a request from his manager to configure the Registrant custom object based on Table 5-1.

He performs the following steps to meet this requirement using record types and page layouts:

1. 1.

   Robin navigates to Setup (gear icon) ➤ Setup ➤ Object Manager ➤ Create ➤ Custom Object and creates a new custom object, Registrant, and all the fields mentioned in Table 5-1.

    
2. 2.

   Next, he creates two page layouts by navigating to Setup (gear icon) ➤ Setup ➤ Object Manager ➤ Registrant ➤ Page Layouts.

    

The Registrant page layout should look like Figure 5-4.

The Manufacturing Registrant page layout should look like Figure 5-5.

1. 3.

   Last, Robin creates two record types—Manufacturing and Others—and then assigns page layouts as shown in Figure 5-6.

    

Going forward, users will get an option to select the record type before creating a Registrant record, as shown in Figure 5-7. Based on the record type, it will display the page layout.

How Record Types Control Lightning Record Pages

I have seen many questions from people, as part of the Trailblazer Community, wondering how record types and page layouts are connected in Lightning record pages. Here is my answer: a record type can control both page layout and Lightning record pages at the same time, because they are separate components.

Still confused on how record types control Lightning pages and page layouts? Well, let me show you an architectural diagram (Figure 5-8) that displays the connections among record types, Lightning record pages, and page layouts.

Figure 5-8 also shows that users in two different profiles can not only have the same page layout, but also they can have different Lightning record pages configured for their profiles—and vice versa!

Basically, in Lightning Experience, you use Classic page layout as a component (Record Detail), which sits on top of the Lightning record page. This means both are separate Lightning components. Therefore, both are configurable at the object level.

After you create a Lightning record page, click the Activation button to assign the Lightning record page based on record types and profiles.

Figure 5-9 demonstrates how you can assign a Lightning record page to record types and profiles in Lightning App Builder.

Lookup Filter: Limit the Records That Can Be Shown in a Lookup Window

A lookup filter is one of the best tools to enrich data quality by enforcing data consistency. The filters limit fields and values displayed in a lookup dialog and, as a result, enforce access to valid values. The filter can be used when objects are in a lookup, master detail, or hierarchical relationship.

Let’s look at an example. Pamela Kline has been given the requirement to restrict the Account Name field on opportunities by only allowing accounts with type Customer and by filtering out any other types of accounts.

Going forward, whenever a sales rep creates a new opportunity, Salesforce only shows the account’s whose type is Customer.

Formula Fields: Small Work, Big Impact

Formula fields are Read Only fields that display values based on a formula’s expression that you define. When writing a formula’s expression, you can refer to fields from the parent object, and it can go ten levels deeper. This means, for example, when writing a formula on an Opportunity object , you can refer to the account owner’s e-mail, as shown in Figure 5-11.

The common objective in all the aforementioned scenarios is to perform some kind of automation. There are a few automation tools in Salesforce and each one has unique features. For now, we will use formula fields to solve the business scenarios just presented. In the next chapter, however, we study several automation tools in depth.

When you reference a field from the parent object in a formula’s expression, this type of formula is known as a cross-object formula , as shown in the screenshot in Figure 5-11. Using cross-object formulas, you can reference a field from the parent object (regardless of the whether the relationship is lookup or master detail).

You can create formula fields on standard or custom objects, but not on an external object. As of the Summer 2019 release, it is not possible to refer to fields on external objects in a formula. Any changes in the formula’s expression are reflected automatically in the formula’s field value.

Let’s rejoin Pamela Kline, a system administrator at GoC, who has been given the requirement to display the annual revenue of a customer on the Contact record.

To meet the requirement, Pamela performs the following steps:

Salesforce populates values in the Annual Revenue field (which is a formula field) for all contacts in the Salesforce database. Remember, formula fields are Read Only fields and no one is allowed to edit their value. Formula fields can be used in list views to filter data, as shown in Figure 5-15.

Rollup Summary Field

A rollup summary field is a custom field used to calculate values from related records and to display the value on a parent record. You can create rollup summary fields on parent records only if the objects have a master detail relationship.

For example, suppose there is a master detail relationship between the College and Student custom objects, where College is the parent object and Student is a child object. Using a rollup summary field, you can display the number of students currently active for each college record, as shown in Figure 5-16.

Let’s rejoin Pamela. She has been given a new requirement to display Sum of Open Opportunities Amount in the Account record. To meet this requirement, Pamela performs the following steps:

Salesforce now populates Total amount (Open opportunities) field values for all opportunities. Remember, rollup summary fields are Read Only fields; no one is allowed to edit their value.

Validation Rules

Validation rules help organizations improve quality of data by verifying that the data entered by users meet business standards. If the data don’t meet the standards, users get a prompt, with an error message, to fix the error, as shown in Figure 5-18.

A validation rule can contain a formula that evaluates the data in one or more fields and returns a value that is either True or False, where true means no error and false means there is an error. You can display the validation rule error message either at the top of the page (1 in Figure 5-18) or next to the field (2 in Figure 5-18).

Going forward, if users update their annual revenue with an amount greater than US$1,000,000,000, they get an error message and have to fix the error before they can save the record.

Custom Permissions: A Way to Bypass Validation Rules

Pamela is very happy. She just got an appreciation e-mail from her manager for all the work she has done, but it’s then followed by another request: is it possible to bypass the annual revenue validation rule for the following users, for now?

• Carolina Lopez, Regional Sales Manager

• Jerry Shannon, VP Sales

• Donna Serdula, Senior Vice President

Pamela is also told that, in the future, the list of users may grow!

Fortunately, Pamela knows how to bypass validation rules for specific users or profiles. For example, she can bypass the annual revenue validation rule for system administrators by adding a condition to check their profile, as shown in Figure 5-20.

Pamela wonders whether there is a better way to handle this requirement. She doesn’t want to modify the validation rule every time she is required to add a new user to the bypass validation list.

Custom permissions to rescue! Pamela learned recently that, by using custom permissions, she can grant users access to custom apps. In Salesforce, she can use custom permissions to check which users can access a certain functionality. Using custom permissions, she can bypass validation rules, formula fields, Process Builder, Apex triggers, and so on. Custom permissions let her define access checks that can be assigned to users via profiles or permission sets.

To meet the requirement, Pamela performs the following steps:

1. 1.

   She clicks Setup (gear icon) ➤ Setup ➤ PLATFORM TOOLS ➤ Custom Code ➤ Custom Permissions, and clicks the New button.

    
2. 2.
   She creates a custom permission, as shown in Figure 5-21.

   

    
3. 3.
   Now she creates a permission set (“Bypass validation rule”) and assigns the custom permission Bypass Validation Rule to it, as shown in Figure 5-22).

   

    
4. 4.

   Next, Pamela modifies the annual revenue validation rule to add a custom permission check. To do so, she navigates to Setup (gear icon) ➤ Setup ➤ Object Manager ➤ Account ➤ Validation Rules and edits the annual revenue validation rule.

    
5. 5.
   She modifies the formula as follows:

   AND(NOT($Permission.Bypass_validation_rule), OR(

          AnnualRevenue < 0,

          AnnualRevenue > 1000000000

          )

   )
    
6. 6.
   To select the custom permission, she clicks Insert Field (1 in Figure 5-23) and then $Permission ➤ Bypass_validation_rule ➤ Insert (2 in Figure 5-23).

   

    
7. 7.

   Last, she clicks the Save button.

    

Pamela assigns the Bypass Validation Rule permission to users Carolina Lopez, Jerry Shannon, and Donna Serdula. And that’s it! Now the validation rule is bypassed for these users. In the future, if Pamela wants to bypass a validation rule for other users, all she has to do is to assign the permission set to those users.

Points to Remember

Hands-on Exercises

Summary

In this chapter, we covered record types and how they include pages in Salesforce Classic vs. Lightning Experience. We also studied different mechanisms to improve data quality using filter lookups and validation rules. Furthermore, we reviewed rollup summary and formula fields by examining a few examples. In the next chapter, we dive into how to automate business processes using out-of-the-box automation tools.