Originally proposed and submitted by Perren Smith.
As a best practice, for the sake of both network efficiency and enhanced security, it is suggested you create one (1) empty or single record table with a limited number of fields and one (1) dedicated layout and name them such that it identifies the table and layout as the file's startup elements. Naming the Table, Table Occurrence and Layout name "Startup" is highly suggested.
A startup table intended to have either zero or one record is added to the file. The reason for a single record is for when a startup-based user validation scheme is implemented (see Extended features below).
The startup layout should be associated to a table occurrence tied to the empty table (or single record), and should be the selected layout for the Switch to layout: check box within the File > File Options... settings.
Using the OnFirstWindowOpen: option within the Script Triggers area of the File Options dialog is the preferred method for arriving at any default target layout for solution startup. This script can evaluate account name, privilege set or any other variety of settings to determine which layout a user should end up on. (e.g. a Mobile vs. Desktop layout)
It is suggested that the Startup Layout be the topmost listed item in Manage > Layouts.
Reduced startup overhead is realized based on the following benefits.
This method of startup ensures the file is opened to a known location with a low load impact, because graphics (other than a potential splash screen) and other elements are not loaded until navigation takes the user to the target layout.
It also prevents the accidental last layout issue because FileMaker remembers the last viewed layout when the file was closed as a locally opened file. This means the file, when opened over the network, without the Switch to layout setting set, would default to the last viewed layout.
The Low Impact Startup comes with many additional features. These are just a few.
Get ( AccountName ) and one record to the startup table, a one-to-one relationship to a Users table allows for both validation and the ability to load user specific settings. Note: Security must be set within the privilege set such that any given authenticated account can only see its respective record within the Users table.