Determining which fields are used in a page layout (in less time than it takes to brew a cup of coffee)

There is a great app called FieldTrip that will let you know which fields are actually populated in records, but deep diving into eclipse, or using brute force, have been the only way that I am aware of to see which ones are actually visible on which page layout.

Until now. By using to retrieve the page layout metadata, along with OpenRefine to parse the XML to a spreadsheet, it becomes ridiculously easy to pull out this information.

Update: the most awesome and powerful Amber Boaz pointed me at an app called ‘cloud config’ that lets you export all your metadata info to excel, including layouts. Its awesome and definitely has a place in the admins toolkit. Using refine as described in this post makes it ridiculously easy to compare field visibility across layouts, and do other fun things, so these are definitely complementary options.

So, to pull this together using refine, first you need to create a simple text file named package.xml, with the code below

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="">

Next, login to and go to migration > retrieve

Select your package.xml file as the ‘unpackaged manifest,’ click ‘next’ then click ‘retrieve’. When the operation is complete, this will pull all of the page layout metadata from your instance, for all objects, into a zip file that you can download by clicking ‘download zip file’


Unzip the zip file to a folder on your computer, then launch open refine. it runs in your web browser, there is nothing to actually install, though you do need a Java Runtime Environment (JRE) on your machine.

Note: make sure you install v 2.6 RC2 from - there is a bug in previous versions that prevents this from working for multiple layouts at once.

Click ‘create project’ and click ‘choose files’.


Multi-select all of the page layout files that you are interested in and click ‘next’. To find the layout files, navigate to the unpackaged > layouts path in the directory where you unzipped the file from workbench.

You should see a page where it lists all the files you have selected.


Click ‘configure parsing options’ and click ‘ok’ to ignore the errors as it tries to parse these as excel files.

On the bottom left, select ‘parse data as XML files’. The preview should quickly update. The option to ‘store file source (file names, URLs) in each row’ should be checked by default. Make sure this remains checked.


Now - important - highlight the first “field” node and click on it as displayed in the image below:


This should get you a nice preview with a simple list of fields. You can play around with selecting other nodes if you want to access additional information on whether the field is editable on the layout, but for simply viewing which fields are visible, this is the best option.


Now click ‘create project’ and boom! - you have a list of all fields with a list of page layouts, which you can export to excel via the ‘export’ option in the top right. Couple this with the field trip app, and you can then see not only which fields are used / not used, but which fields are visible / not visible, and go deep on your metadata.

But before you go jumping to excel, try creating text facets on each column as it allows you to easily output a list of fields by page layout, or a count of the number of layouts a field is used on, or click on a field to see which layouts its used on. There is so much you can do with Refine that this is just getting started.


I highly recommend purchasing ‘Using Openrefine’ to get the most out of open refine. It is a good book that will get you running quickly with this amazing tool. I dont get anything from your purchase, its just a great way to get started.

Now I’m wondering what other metadata types I might be able to examine in some way via openrefine. Maybe reports, or permission sets, or … who knows!


Now read this

Visualforce page to embed the flow on

This post is part of a series on building a replacement for stay-in-touch using visual workflow The visualforce page is very simple, no controller required. It is designed to pull the contact ID from the query string (the URL). This help... Continue →