I’ve been configuring Salesforce for Clients for the better part of a decade and one of the recurring themes that we’ve come across is the requirement for dynamic rendering. When it comes to dynamic rendering, it usually involves one or more of the following:

  • Dynamic Reporting (i.e. “My Team’s Opportunities” for managers)
  • Dynamic Dashboards (“Running User” functionality)
  • Dynamic List Views (i.e. “My Accounts”)
  • Dynamic Sales Stages (i.e. Sales Process/Record Type mapping, added bonus for Path configuration to display different fields and “Guidance for Success” at the different stages)
  • etc etc

However, as you may have guessed, the most common request is to dynamically render fields and buttons on an object when viewing a particular record. We see this most often when working with Opportunities but a close second is the CPQ Quote object. We’re going to cover the typical use cases when working with CPQ Quotes and outline how dynamic forms makes our lives tremendously easier, compared to the steps we used to have to take to achieve the requirements that most clients have when it comes to quoting.

What are Dynamic Forms?

Dynamic forms are a new feature of Salesforce that was rolled out for us as of the Summer ’20 release. Essentially, it allows us to dynamically display fields and buttons on a Lightning Record Page without having to be dependent upon Page Layouts or Record Types. This makes our experience building capabilities significantly more impressive and we no longer have to work with the same metadata elements to deliver these user experiences as we had to prior. Using new features and the Lightning Record Page Component Filters, we can control the rendering of the new “Field Sections” component as well as individual fields and buttons.

IMPORTANT: Dynamic forms are currently only available on Custom Objects, we will most likely have to wait until Spring ’21 until they’re supported on Standard Objects.

How to Enable Dynamic Forms

To get started using Dynamic Forms, head into your preferred Sandbox environment (you can enable directly in Production but you know better than that 😉). From Setup, enter “Record Page Settings” into the search bar and you’ll see the option to enable Dynamic Forms.

Dynamic Forms Salesforce CPQ

Once you’ve enabled Dynamic Forms, you can then head over to a Custom Object Lightning Record Page and click “Edit”. From the Lightning Record Page Editor, click into the “Record Detail” component to see the options you now have available and you’ll see the option to “Upgrade Now”, which will walk you through the process for converting your Record Detail component into the new “Field Sections” components.

Dynamic Forms Salesforce CPQ

After clicking “Upgrade Now”, you will be prompted to indicate whether you want to create Accordion and Field Section components from your existing Record Detail page sections. This essentially converts the different page layout sections from your Page Layout into separate Accordion components, with each Accordion component having its own Field Section component. I typically choose this option but combine all of the Field Section components into one area and remove the Accordion components because I don’t like having to manually expand each Accordion if I want to see different elements of the record (Accordion components only allow for one Accordion to be expanded at a time).

Dynamic Forms Salesforce CPQ

How do Dynamic Forms Work?

Now that you’ve enabled Dynamic Forms, you’ll see that you have the new “Fields” tab within the Lightning Page Builder, next to the standard “Components” tab. This allows you to insert Field Section components into your Lightning Record Page and also allows you to add individual fields to a Field Section, similar to how you would add fields to a Page Layout.

Dynamic Forms Salesforce CPQ

In addition to being able to drop in Field Sections and Fields, you can also control which buttons you want to display within a Page Layout by clicking into the Highlights Panel component and clicking the “Enable Dynamic Actions” option.

Dynamic Forms Salesforce CPQ

CPQ Use Case for Dynamic Forms

Now that you’re familiar with the basics of Dynamic Forms, let’s take a look at a common request we see from CPQ Clients. For those of you that are familiar with CPQ, the flow is typically the following:

Create Quote → Add/Edit Line Items using the Quote Line Editor → Submit for Approval → Mark as Primary → Generate Proposal → Send Proposal to Client → Mark Quote as Accepted → Order Quote

The ability to edit the Quote Lines, Submit for Approval, Generate Proposal and, if using DocuSign or Adobe Sign, Send Document for Signature is controlled using Buttons on the Quote object while the ability to mark the Quote as Primary, indicate the Quote as Accepted and Order the Quote is controlled using fields.

The most common requests that Clients have are the following:

  • Cannot Submit the Quote for Approval unless certain requirements are met
  • Shouldn’t see the “Submit for Approval” button if already Approved
  • Cannot Edit the Quote Lines after the Quote has been Approved
  • Cannot Generate Document until Quote has been Approved
  • Cannot Order Quote until Quote has been Accepted and is marked as Primary

Now that we’ve outlined the Use Case, let’s take a look at how we used to deliver on this functionality before Dynamic Forms.

SFDC Configurations without Dynamic Forms

Without the functionality that Dynamic Forms provides, the following is an overview of how we had to configure Salesforce to meet the requirements listed above:

  • Record Types
    • Creation of “Unapproved” Record Type for the Quote object
    • Creation of “Approved” Record Type for the Quote object
    • Creation of “Accepted” Record Type for the Quote object
  • Page Layouts
    • Creation of Unapproved Page Layout, assigned to “Unapproved” Record Type
    • Creation of Approved Page Layout, assigned to “Unapproved” Record Type
    • Creation of Accepted Page Layout, assigned to “Unapproved” Record Type
  • Profiles
    • Assignment of Page Layouts to each Profile
    • Assigning of “Unapproved” Record Type to all requisite Profiles
    • Removing “Approved” and “Accepted” Record Types from all Profiles
      • We didn’t want the Users to be able to create or select any record type besides “Unapproved”
      • This provided a challenge when Users needed to Clone a Quote that had been assigned the ‘Accepted“ Record Type
  • Approval Processes
    • We needed an Approval Process that lived on the Quote object and would update the Record Type to “Approved” upon Approval
  • Process Builder
    • We needed a PB that would update the Quote Record Type to “Accepted” when the Quote Status was “Accepted” and the “Primary” field was checked
      • We also had a Rich Text Component displayed on the Lightning Record Page to let the User know that in Order for the Quote to be “Ordered” the Status had to be “Accepted” and the “Primary” field had to be checked in order for the “Ordered” checkbox to be visible
  • Validation Rules
    • Last but not least, we had to create a couple of fail-safe validation rules to ensure the following:
      • Ensure a Quote wasn’t created with either the “Approved” or the “Accepted” record types (cloning)
      • Ensure the “Ordered” box was only checked if the Status was “Accepted” and the “Primary” field was checked

As you can see, that is a decent amount of Metadata configurations that needed to be made to deliver the requirements above. If any changes needed to be made to the Quoting process, all of those elements needed to be evaluated and regression tested to make sure nothing broke. If changes did need to be made, we would have to jump in and out of 6 Setup screens to accommodate those changes as well.

In addition to the number of configurations that needed to be made, if there were other requirements for conditionally rendering fields and/or buttons, we had to hope that the logic allowed for the fields to be displayed against one of those 3 record types. If not, then we’d have to jump through a lot more hoops to deliver on the new requirements.

Overall, this was not ideal. Salesforce realized this and gave us shiny new functionality with Dynamic Forms. Let’s take a look at how much simpler it is to deliver on those requirements using that functionality.

Solving the CPQ Use Case with Dynamic Forms

With Dynamic Forms, we can deliver on all of those customer requirements in one fell swoop. Let’s break them out individually:

Requirement #1: Control Visibility of the “Submit for Approval” button

  • Users should not be able to see the Submit for Approval button unless certain requirements are met
  • Users should not be able to see the “Submit for Approval” button if the Quote is already Approved


  • Using Dynamic Actions, we can add the “Submit for Approval” button to the Highlights Panel and add a Filter based on the logic the Client wants to implement. In this case, let’s say that the User shouldn’t be able to submit the record for approval until the Quote has an Amount and the Start Date is known.

Dynamic Forms Salesforce CPQ
Requirement #2: Control visibility of Edit Lines and Generate Document buttons based on Quote Approval status

  • Cannot Edit the Quote Lines after the Quote has been Approved
  • Cannot Generate Document until Quote has been Approved


  • Create Approval Process that updates a custom field (Approved__c) to True upon Approval
  • Similar to the scenario above, we’re leveraging Dynamic Actions to conditionally render buttons based on record details. In this example, we just need to filter on a single field that is set during the Approval Process (Approved__c)