FMPerception is a ghost-hunter, and a successful one at that. The realtime developer intelligence tool can point out all the ‘phantom fields’ on a layout. Let’s take a look at FMPerception’s successful ghost hunt.
What are Phantom Fields?
Unlike the prey of Ghost Hunters, phantom fields are real. They are the fields that are on a table view.
The fields are added in the Modify Table view dialog.
These fields are not on the layout in layout mode.
They haunt the layout, seen only in Table view. They are phantom fields!
One note: the term Phantom Fields doesn’t come from FileMaker. Instead, the term is how FMPerception defines these. Just so you know.
Giving up the ghost
FMPerception identifies these illusive phantom fields on any layout. 
While looking at a layout, I can view all the layout objects. Each one, if it is on the layout, has a region designation. Phantom fields have the region “Phantom Field”. So if I wish, I can remove those from the layout.
Do I need to get rid of these?
I would say no. These phantom fields are there for a reason. They show themselves only in table view, and if someone has the correct privileges, phantom fields can be added for custom views. With the same privilege set, these phantom fields can be removed from the layout.
FMPerception doesn’t have a report for Phantom Fields like it does for “Unreferenced Objects” or “Broken References”, since phantom fields are not detrimental to a custom app in any way. FMPerception simply identifies them for you on each layout.
So be aware of phantom fields on layouts that allow Table view. And be aware of the identification of these fields in FMPerception. They are of little consequence overall, and they allow quick access for users to create a custom view of the data.