Most efficient way to navigate to the new layout

I'd like to create a script that will make a new related record by navigating to a new layout, creating a record, then returning to the original layout. I'd like to use this method, and not the magic key method.

What is the most efficient way to navigate to the new layout where I will be creating a record? Doesn't FileMaker load 25 records or something when you navigate to a new layout? Does Freeze Window prevent that?

I've read in the past of people entering find mode, then entering bogus find data in the new layout, then executing a find in the new layout so that 0 records are returned.

Is there a great way to do this that doesn't involve FileMaker downloading unneeded data from the server?

I have not tested the two alternatives, so I don’t know which is fastest.

FileMaker does preload records, although this will only be an issue on the first hop, after that they will be in memory.

If you are focusing on performance create blank layouts for your scripts.


Typically, I use the following sequence in a script that creates a related record:

  1. Freeze Window
  2. Get script parameters (i.e. parent record ID)
  3. Go To Layout ( target layout based on target related table)
  4. Create new record
  5. Set fields (i.e. parent record ID as foreign key)
  6. Commit record
  7. Go To Layout (Original)
  8. Refresh Window or portal (optional, if necessary)

For performance reasons, the target layout is blank, as @Malcolm suggested.


@nihm What makes you ask the question in the first place? Are you experiencing anything that is not in line with what you want/expect? Do you plan on involving that navigation in another process where it would become taxing? Or are you simply looking for a "best practice"? What makes it so you do not want to rely on magic key?

Thank you for any additional context you may provide.


Thanks everyone for your replies

Or are you simply looking for a "best practice"?

Exactly. This is something I researched years ago, and now that I'm writing a bunch of scripts creating related records in this manner, I wanted to revisit the issue.

For me, the fact that you do not switch contexts is a big winner for the magic key technique. Switching contexts can cause other things to happen.

I've run a few tests using magic key and switch layout methods to create 10,000 records.

Magic Key method runs in approx 5 seconds or 0.5 milliseconds per record
Layout switch runs in approx 20 seconds or 2 milliseconds per record

Testing is done on a clean test file.

A production system will have larger record sets, complex layouts, and potential for layout script triggers. Those factors will all make the layout switch technique slower and introduce potential problems.

1 Like

Another variation is to create a new window:

  • Freeze Window
  • Get script parameters (i.e. parent record ID)
  • New Window (Layout based on target related table)
  • Create new record
  • Set fields (i.e. parent record ID as foreign key)
  • Commit record
  • Close Window

I haven't tested this for performance. I would guess it's slower than GoToLayout, but has the advantage of not altering anyting in the original window (e.g. scroll position, which Tab is selected in a tab panel, etc.)

1 Like

this is what I'm doing (too)

and since FM16 one can directly call the context in one (script-) step getting out of the way of layout triggers and larger payloads of the recent layout

plus adding to a portal can now trigger a refresh-layout-object to circumvent having to reload the complete original context

I found card windows handy for this. It avoids layout triggers and can act as a decent UI.

The attached sample has a layout (child table) call processing, with a single header part, no body.

This layout is used for the card window/UI as the record is added. (86.5 KB)


This is my preferred method at the moment for adding single related records. It's really flexible, it has the possibility of multi-window processes and it doesn't interfere with the state of the current record/layout.

Opening a new window ist the most time consuming process in FileMaker. If you're looking for a solution that is as fast as possible, nothing beats the creation of a related record via a relationship.

In order to do this you need a new global field 'ID_CHILD' in your parent table, that holds the next id for your child. This field is part of the new relationship 'parent_CHILD_add', in which creation of new records is allowed. The rest is a simple 3 line script, that calculates the next ID of your child into your global field and writes the child data directly via the relationship. (see example file).

create-related v2.fmp12 (300 KB)

The creation of the new records is as fast as you are able to click your mouse button. :grinning:

I would prefer UUIDs over number IDs. In this case simply set the global field to 'get(UUID)'.


I had previously read creating records was extremely time consuming. Anybody have references on this subject?

On the topic of different methods for creating child records:

I always have had a lot of appreciation for an approach that I learned from Perren Smith. I believe that this approach is documented in a white paper by Chris Irvine and Perren.

It is an available option in separation model solutions, where the CRUD scripts happen in a file which is separate from the UI file. Essentially, if the user is on any layout in their UI, and they need to create some kind of record(s), their action in the UI file results in the invocation of a CRUD script in the "CRUD file", which is tasked with creating the records. The CRUD file spends its entire lifecycle as a hidden file, and thus it is able to navigate to layouts as needed without any disruption to the user (either visual, or any change of context or found set).

Additional points:

  • As much as I really like this design, I've only used it in production once (it worked great), because nearly all of the solutions that I have been working on in recent years have been single file (no separation model) architectures.
  • If speed is the primary concern, then I think this will be slower than creation of records via relationship, but faster than opening up a new window.
  • I discovered this approach at a time when I was knee-deep in solutions that were opening up new windows to create new records, and I much preferred it. I think that whether or not it strikes one's fancy is a question that is very much related to how one feels about deploying solutions with the separation model.

There are a few questions implied here.

Before navigating to any new layout, enter find mode first. Then do your find to the set of records you want ; or search for an empty primary key, or show all > omit records. Any of these techniques will get you to another layout quickly with no data showing.

You can also navigate to a new off screen window in the child context that has no content (nothing for FileMaker to populate) and do your scripted entry there.

But the other question; creating records in a related Table easily.

A technique I call a ghost portal is used. The child table is set with create through relationships true. If you show the child portal, hide the fields of there is no primary key - keeps the presentation clean and as the ghost record is at the end of the list of portal records, eliminates the confusion finding the end record entry place to enter data or beyond the size of the number of records shown in the portal.

Then create a single row portal from the same child table. Set the filter on that portal to false. This ends up representing the not-quite-a-record fields (the ghost record) that shows up in a portal where create through relationships is true. Now any fields from the child records in this new ghost portal will be available for entry…. but on commit, they disappear only to miraculously appear in the larger portal from the same child TO as a new record. You can even put a popover on a button in that one row portal with data entry fields in the popover window.

I often just put a plus icon in the 1 row ghost portal with the popover for the data entry fields adjacent to the larger portal. Small, Clean UI and easy to implement.

The 2 critical pieces of execution; create through relationship on and a portal filter on the second tiny portal to “false”.


Really nice tip regarding the portal filter set to False to just show the "ghost record". I've never seen that technique before. Thanks, @Kirk ! (And welcome to the Soup!)

1 Like

That’s my preferred method for creating related records too. Superfast!
And welcome to the soup!

Using False as a portal filter is a useful trick. Thanks for sharing that @Kirk .

@Kirk Ghost portal looks very interesting. Do you have a sample file or video you could share to help us not so expereinced guys better grasp what you are doing? Thx!

Not really but it could be easily created. Parent table - child table related. Create through relationship on. Layout from parent with child portal. Or will show the fields for a new entry at the bottom which is not necessarily a great UX especially of the portal records exceed the row count in the portal.
Create a second portal….a duplicate of the one already existing. Make it one row tall and set the portal filter to false. Now that one row portal is your data entry for the child table and on commit, will show the new data in the main portal while clearing the one row ghost portal automatically.
For a better UX the main portal fields should be hidden off the primary key is empty.
Or you could create the ghost portal and the display portal from different table occurrences based on the same base table
You can also make the one row ghost portal the size of a single popover button for adding new records while the main portal only displays key information


I really like this discussion about the creation of simple related records and I think the "ghost portal method" is interesting for this kind of process.
I just wanted to add some information to this as someone might find this handy.

There was a slight drawback for me concerning the use of this technique:
If you commit the record by clicking outside of the ghost portal you can not establish any control on the creation of related records.
Therefore I used the work around of putting the ghost portal into a popover which I had made modal. Here I could prevent the commit unless a specific button was used to close the popover.
Still there was a last problem: If you use this apporach in webdirect and a user clicks on the frame of the popover the record is still commited although the popover remains open.

You can work around this problem by putting the ghost portal with its fields into the popover and then make the portal modal and not the popover (the user therefore can not leave the portal itself). Of course the button to close the popover must be in the portal row as well.

If I have the time and someone is interested I can come up with a small technique file to illustrate the point, although it is only necessary if you want to use it in webdirect and if you want to have this degree of control on record creation (checking for mandatory fields,...).