Using SFDX & the Metadata API to Compare Page Layouts Between Salesforce Orgs

Have you ever gone live with a Salesforce implementation or enhancement project only to realize that what the users see on the screen doesn't match what they saw during UAT testing? You may have forgotten to deploy your page layouts or lightning record pages. In this article, I'll talk about how to rapidly identify the differences in page layouts and lightning record pages between two Salesforce orgs using sfdx and the Metadata API.

Prerequisites

Steps

  • Follow the prompts to select a project name and designate what root folder the project should be created in
    • Select the empty template
  • Expand the manifest folder and open the package.xml file
  • Replace the contents with the package.xml file from this GitHub gist
  • Open the command palette and run SFDX: Authorize an Org to connect to your source org
  • Right-click on the package.xml file and select SFDX: Retrieve Source in Manifest from Org
  • Open the integrated terminal
  • Enter the following commands
    • git init
    • git add .
    • git commit -m "initial commit of source org"


  • In GitKraken, open the git repository you've created (the sfdx project folder)
  • Click the Stage all Changes button in the top right of GitKraken




  • In the bottom right of GitKraken, enter a commit message and click the Commit changes to button

    • In VSCode, open the command palette and run SFDX: Authorize an Org to connect to your target org
    • under the force-app/main/default folder, delete the flexipages and layouts folders
    • Right-click on the package.xml file and select SFDX: Retrieve Source in Manifest from Org
    • Observe the Unstaged Files section in GitKraken
      • Files with a green plus icon exist in the target org but not the source org - it is likely that no action is needed here
      • Files with a yellow pencil icon exist in both orgs, but are different between the two - review the differences and decide whether or not to deploy this artifact to the target org
      • Files with a red x icon exist in the source org but not the target org - you will likely want to deploy these artifacts to the target org, along with the associated apps, profiles, and permission sets 
    • If you click on a file with a yellow pencil icon, you can see the differences between the file in the source org (on the left) and the target org (on the right)


  • Make sure you have selected the split view icon directly beneath the Stage File button


    • Comments

    Post a Comment

    Popular posts from this blog

    Embracing Package-Based Development on the Lightning Platform: Separating Triggers into Multiple Packages

    Image
    Consider a case where you might want to have a package hierarchy. As an ISV or Consultant, you might create a package for an industry, and then one or more packages for each business unit under that industry. As a best practice, you should have a single trigger and trigger handler class per object. This allows you to control the order in which trigger operations can occur. Let's say you use the package hierarchy below: The tricky thing here is, while you will want to install the industryCommon package for every customer, the same isn't true for the child packages. For a given customer, you might want to install businessUnit1, businessUnit2, or both. Given the package hierarchy above, it's not possible to have a single trigger on the Contact object. That is, until we leverage the power of Interfaces and the Type class. To implement apex best practices, we will need to create a single trigger and trigger handler class in the industryCommon package. When we are ...
    Read more