Org Documentor - Fields Usage in Page Layouts

The November meetup of the London Salesforce Developers saw us sharing our favourite tools, those we use regularly and those we have written ourselves. I showed the Org Documentor, and got a great question from Lawrence Newcombe - does the information output for the custom fields include details of which page layouts they are used on. The answer was no, but definitely doable. And here we are less than a month later and it's done! 

There's no additional configuration required, but as always remember that it only works against the metadata that you have retrieved from your org. If fields or page layouts aren't present on disk, they won't appear in the report.

Output

I've had to tweak the format of the report slightly, as the layout names can be quite long so I needed more real-estate. For those that care about the bootstrap side of things, the main bodies of the pages now use the container-fluid class rather than container, as this allows them to take up most of the width of the page.

The fields table now contains a new column - Page Layouts - which has the layout name and the behaviour.

As the names can be quite long and there can be multiples, the behaviour is in bold and there's a separator between each layout. 

This output was generated from the sample metadata and can be viewed online.

Processing

Much like the last enhancement I added, aura enabled classes, I was again pleased by how little code needed adding. I loaded the page layouts from the source folder and iterated the layoutItems entries. For each of these I created an ObjectPageLayoutData record and stored this in an array associated with the object and field combination. I then cached this information in a map, keyed by the object name, followed by a ':', followed by the field name.

When generating the field record, after it has been enriched with any extra information, I then retrieve the cached ObjectPageLayoutData array for the object name and field combination, and add this to the object information that is passed to EJS to generate the HTML.

In the HTML template, I check to see if there are any ObjectPageLayoutData entries, as fields don't have to be present on layouts, and if there are some, I iterate them and output the layout name and the behaviour (Required/Edit/Readonly). As there can be multiple entries, and the names can be quite lengthy, I add a thematic break tag (<hr/>) after all but the last item in the array (and I also think it's pretty cool that in an EJS HTML template I can iterate an array and tell if I am on the last entry!).

Plug-in

Version 3.3 of the plug-in has this new functionality and can be found on NPM. 

If you already have the plug-in installed, just run sfdx plugins:update to upgrade to 3.3.

if you aren't already using it, check out the dedicated page to read more about how to install and configure it.

The source code for the plug-in can be found in the Github repository.

Related Posts

• The plug-in on NPMJS
• Documentation generated from the sample metadata
• Sample metadata repository
• Plug-in source repository
• Org Documentor and AuraEnabled Classes
• Documentor Plugin - Triggers (and Bootstrap)
• Documenting from the metadata source with a Salesforce CLI Plug-in - Part 5
• Documenting from the metadata source with a Salesforce CLI Plug-in - Part 4
• Documenting from the metadata source with a Salesforce CLI Plug-In - Part 3
• Documenting from the metadata source with a Salesforce CLI Plug-In - Part 2
• Documenting from the metadata source with a Salesforce CLI Plug-In - Part 1
• Offline mobile app template plug-in Dreamforce 18 session
• Salesforce CLI Play-by-Play
• Salesforce CLI Cheat Sheet

Follow @bob_buzzard