Master-Detail Layouts in FileMaker

FileMaker 17’s new master-detail layouts display the list of records in the user’s found set. As the user performs finds, constrains, omits, sorts, or creates or deletes records, the master-detail portal will update to stay in sync. Imagine a portal that a user can sort any way they like, filter any way they like, and click a row to see details for that row, all right out of the box. That’s the power of the master-detail portal.

FileMaker Developers have long tried to approximate a master-detail layout using the tools available to us at the time. Prior to FileMaker 17 one option was to use a native list/table view, and show the details for the active record in the layout’s footer. Another option was to base a layout on an abstract global/interface table, with portals peering into related data tables. Or by using a self-join relationship that somehow figured out which records were in the user’s found set.

Now we can easily display a space-efficient list on the left of the layout (or wherever you like), with the details of the active record displayed to the right of that list—with no extra code. The master-detail layout combines a bird’s-eye-view list view with a record-focused form view.


To use this feature, configure a portal via the Portal Setup dialog to “Show records from…Current Table”. Note that you are selecting the same table occurrence that the layout is based on, rather than selecting a related table.


That’s it.

You’ll find fewer possible configurations than with a “Related Table” portal, because many of these actions come for free by leveraging the found set.

  • You can’t filter the portal, because the portal filters itself in response to changes in the user’s found set (e.g., via finds and omits).
  • You can’t sort the portal, because the portal sorts itself in response to a change in the found set’s sort order.
  • You can’t “allow creation of records via a relationship”, but you can just create a new record in the found set.
  • You can’t delete a portal row (via selecting that row), but you can delete the active record. You can also place a delete button on the portal row, which first makes that row the active record, and then deletes it.

(Note that if you copy this portal object and paste it onto a layout with a different underlying table occurrence, it will convert automatically to a “Related Table” portal.)

Let’s look at a few examples.

Example 1: Record Navigation

A master-detail layout displays information to the user about their found set that helps them navigate through those records. The Actors.fmp12 example shows a master-detail layout at its simplest: click on any name on the left to see the corresponding details on the right.

Without moving off their active record, or sacrificing access to a form view’s assortment of data entry fields, the user is able to see information about other records in the found set, informing the user’s decision about which record to click on next.

Example 2: Search

Master-detail layouts support Find Mode just like traditional portals do, but we can do a few cool new things as well.

The Things.fmp12 example uses an old technique to flatten unlike objects (people, companies, attachments, addresses, action items, topics) into a single display table. The user may click a thing on the left to see that thing’s details on the right. (Thanks to conditional visibility, we see fields only from that thing’s corresponding data table.)

What’s new with using a master-detail layout is the user is free to modify which records are visible in the portal, including using quick find to search across all data tables simultaneously. That’s search power!

One limitation of allowing a user to search on a form view layout has been that it’s difficult to visualize separate find requests, because a form view shows only a single request at a time. A master-detail layout gives us more options in Find Mode to show a user what their find request is before they execute it. Note in this example how the Get ( RequestOmitState ) function is used to indicate if a find request is omitting its criteria.

Performance doesn’t seem to be an issue. Whereas I tend to shy away from traditional portals showing more than a few hundred records, I’ve been able to scroll through a master-detail portal’s records quickly even when the found set includes more than a million records, and even when the portal includes fields from related tables. (Performance testing done on both a local and hosted file.)

Example 3: Visualization

The MCU.fmp12 example demonstrates a few of the many ways a master-detail layout can help the user visualize the data in their found set. In this example a master-detail portal is placed on each of a tab control’s panels, with each panel auto-sorting the found set in a way that is meaningful for that particular portal.

The Title tab sorts alphabetically by title, showing how images and text can work together to help the user to click on the most relevant record. This is similar to how the Mail app on macOS can preview part of the body of the email.

Note how the description text changes color for the active row, to ensure readability against the change in background color. In the past I might have done this by having a button capture the click and cache the clicked row’s ID. Now we get the row click for free, get the row highlighting for free (via the pre-existing Active state on the portal row), and can use the new Get ( ActiveRecordNumber ) function to color the text, via the below calculation.

Get ( ActiveRecordNumber ) = Get ( RecordNumber )

The Year tab uses an old trick to approximate sub-summary parts in a portal, by having spacer lines conditionally appear at breaks in the summary value, and summary values conditionally hide when they are repeating. What’s really cool about this example is how simple it is: unlike with a traditional portal, master-detail portal objects respect the GetNthRecord function relative to the found set (and therefore relative to portal rows), so each row can easily look up or down the list at adjacent values to determine if they are the first/last of their respective summary block.

Here’s a sample of how the Year field conditionally hides itself when it’s not the first row of its summary block.

Get ( RecordNumber ) > 1 and MOVIE::YEAR = GetNthRecord ( MOVIE::YEAR ; Get ( RecordNumber ) – 1 )

The Runtime tab is similar to the Year tab in that it sub-summarizes data (here grouping the movies into blocks of 8 hours, in case you want to pace yourself when watching them all in sequence), but with a summary field thrown in. Nothing new here in terms of portals and summary fields interacting, except that the user now can be in full control of which records are visible in the portal, and in which sort order, which can make the summarization more meaningful.

The Franchise tab is very similar to the Year tab, except it has two levels of sub-summarization, approximating a hierarchy.

The Tickets Sold tab displays a very simple ‘chart’ of millions of tickets sold in the US. The ‘chart’ is another old trick, this time with a repeating field. This gets close to being an interactive chart in the sense that the user can click on a value in the chart (an individual portal row) to see details about that value.

(Note: because the master-detail layout employs a portal, it respects the same restrictions imposed on traditional portals: the master-detail portal cannot contain a chart, web viewer, or other portal.)

All of these visualization techniques were possible with FileMaker 16, but in some cases they are now easier, and in all cases they can now piggyback off the power of the user’s found set.

Advanced Techniques

Let’s try to stretch the master-detail layout a bit.

Example 1: Custom Sorts

The Clickable Column Headers.fmp12 example is similar to the MCU example, except it unifies several tabs into a single portal. The column headers are clickable to sort the found set (and therefore the portal), caching a value that tells the headers and portal which column the user sorted by.

This example is ‘advanced’ because it also supports manual sorting, via a custom menu. After the user sorts their found set, a script tries to determine how the records have been sorted; if the sort order is recognized, the column headers and summary objects display accordingly. This leaves the user free to sort how they like, yet still get meaningful visualization results. (This technique uses several, possibly expensive ExecuteSQL queries, and so wouldn’t be recommended for large record counts.)

Here we use the List Of summary field in a new way. In the past, if I allowed a user to filter a portal, I had to do some extra legwork to programmatically identify which records were being displayed in the portal as a result of the filter. Now it’s as easy as looking to a List Of summary field, since the portal’s records and sort order will match that of the found set.

Example 2: Sidebars

Something I appreciate about sidebars in an app like Mail is that I can resize it or even close it. Real estate is precious, so why not let the user decide if they want the sidebar or not? Take another look at that Actors.fmp12 example. If you hover over the righthand side of the master-detail portal, a vertical delimiting line appears. That line is a button, and if you click it…

…the sidebar closes. Now the delimiting line is hiding on the left of the window. Hover over it to make it appear; click it to reopen the sidebar.

This discoverable approach is perhaps too subtle, and/or too dissimilar to the metaphor used in existing apps. But regardless how you implement it, you can leverage buttons and conditional visibility to let the user regain that real estate at their discretion. You could employ this technique to quietly introduce master-detail portals into an existing interface that users are already familiar with: the portal could be hidden by default, but via some new button the user could opt to expose it.

Example 3: Record-Level Sorting

I’ll close with the Manual Sort.fmp12 example, to emphasize one last time how much I love FileMaker’s found set. I never tire of the ability to micro-manage which records I’m looking at: between finds, omits, and sorts, I can almost get my record sets to look exactly as I want. Almost. One thing that FileMaker doesn’t give us right out of the box is record-level sorting, by which I mean the ability to say “Show me record C first, then record A, then record B”.

I’ve long used the drag-and-drop technique pioneered by others to achieve this level of record-by-record sorting (especially useful for ranking movies). In this example, if I drag one movie poster onto another, a movie moves up or down the list accordingly. Though the technique isn’t new, here I’m performing the drag-and-drop in a portal, yet effecting a change in the found set’s sort order.

Since the drag-and-drop behavior is now operating on a found set, what happens if you constrain to a subset of records (e.g., records 5, 10, and 15), and then re-order just that subset? The script allows that subset of records to exchange positions, but only relative to each other. When the records are reintroduced into the total record population they won’t, as a group, have changed position relative to any other records (e.g., whatever order they are in, they would still be in positions 5, 10, and 15). Open up the script to see how this is done.

So I get the power of a condensed, customizable list (in the form of a portal) paired with the details for any item in that list that I click on, and with the records in an exact order of my choosing.

Super cool.

Leave a Reply