Introduction
As you build more sophisticated FileMaker applications, understanding the right tool for managing temporary or persistent values becomes essential. FileMaker offers several options — global fields, global variables, and global tables — each with distinct behaviors and ideal use cases. Misusing them can lead to unpredictable results, especially in multi-user environments.
In this article, we break down the differences, provide real-world examples, and help you make informed decisions about when and how to use each.
What Are Global Fields?
Global fields are fields with storage set to "Global" under Field Options. Their contents are:
- Session-specific: Each user session sees and edits its own version.
- Resettable: They reset to the last saved state upon opening the file.
- Shared across layouts: Values are accessible from any layout or script.
When to Use Global Fields
- Storing filter selections across multiple layouts
- Staging values for search criteria
- Temporary user session values (e.g., active user ID, search date range)
- UI control elements (e.g., toggles, flags, active tab names)
Important Notes
- Global fields only retain their values if edited in single-user mode or during scripted deployments.
- For hosted files, values entered in a global field by a user are not visible to others.
What Are Variables?
Variables are memory-resident values defined using the Set Variable script step. They come in two forms:
1. Local Variables ($localVar)
- Exist only within the current script or calculation context
- Deleted when the script ends
2. Global Variables ($$globalVar)
- Persist across all scripts, layouts, and contexts within the user session
- Deleted when the file is closed or the session ends
When to Use Variables
- Local: Temporary calculations inside scripts
- Global: Session-wide preferences, IDs, temporary sort orders
Advantages
- No need for schema changes
- Super fast access
- Ideal for scripting and UI interactions
Limitations
- Invisible to users (not shown on layouts unless explicitly placed in merge text fields)
- Not saved with the file
- Lost on logout or crash
What Are Global Tables?
A "global table" is a developer-created table meant to store global-like data using a one-record-only design. It usually includes fields like:
- Current user's full name
- Environment flags (e.g., isAdmin, hasReportAccess, expandedLayouts)
- Global preferences
- UI settings or constants
When to Use a Global Table
- You need values that persist across sessions and users
- You need to store editable session info per user
- You want values visible on layouts or in conditional formatting
Implementation Tips
- Restrict the table to one record only (can be enforced via validation or script on open)
- Load values into the global fields or global variables during startup scripts
- Lock down access if using it for session logic to prevent user edits
Comparison Table: Global Fields vs. Variables vs. Global Table
Real-World Example Scenarios
Global Fields
- Search Filters Across Layouts: Utilize global fields to enable users to enter filter values once and apply them across multiple layouts. Each user's values won't interfere with others.
- User Login Timestamp Logging: Capture login time per session using a global timestamp field — useful for internal audits without altering shared records.
Variables
- Scripted Workflow Flags: Utilize global variables to track elements such as user roles, sort order, or mode flags across scripts without requiring additional fields in the schema.
- Modal Context Transfer: Pass multiple values between modal layouts using local or global variables, rather than creating temporary fields.
Globals Tables
- Theme Toggles or Admin Controls: Use a global table to persist settings, such as "Reports Access" or “Admin View Enabled," across sessions, or even allow toggling via buttons visible on the interface.
- App-Wide Configurations: Store constants such as system name, branding colors, or environment type (development, staging, production) in a single, global record accessible across the system.
Global Fields and Variables in Server-Side Scripts
When working with FileMaker Server-side scripts — whether triggered by scheduled jobs or using Perform Script on Server (PSoS) — it's crucial to understand how global fields and variables behave differently compared to client-side sessions.
Global Fields in Server-Side Scripts
- Global fields can be used in server-side scripts, but their values must be set within the script itself. Server sessions do not retain user-edited global values.
- Values stored in global fields during server-side script execution are isolated to that script session.
- Global fields used for filtering or staging data must be explicitly set and cleared in the script.
Best Practices:
- Always initialize global fields at the beginning of a server-side script.
- Avoid relying on pre-set values, as the server will not load global field values saved by a user session.
Variables in Server-Side Scripts
- Variables, both local and global, are fully supported in server-side scripts.
- They behave identically to client-side execution: local variables exist only within the script, and global variables persist through the duration of the server session.
Best Practices:
- Use variables for dynamic logic, counters, and managing state between script steps, as well as JSON structures.
- Remember that global variables ( $$ ) will not persist beyond the server script's session. They are destroyed when the script completes.
Common Pitfalls to Avoid
- Assuming global fields retain values across multiple server-side scripts, they don't.
- Failing to set up the necessary global fields at the beginning of the script results in missing or default values.
- Using global fields in server-side filters without populating them results in empty or incorrect finds.
By understanding these nuances, developers can confidently build reliable server-side workflows that behave consistently and deliver accurate results.
Conclusion
Choosing between global fields, variables, and global tables depends on your specific needs — persistence, scope, visibility, and user isolation. FileMaker provides flexible tools, but with flexibility comes responsibility. Use this guide to select the best storage strategy for your application's goals.
FAQs
1. Can global fields be used in relationships? Yes, they're excellent for dynamic filters or portal selectors. I like to use them for multi-keys to simplify complex relationships on the Table Relationship Graph.
2. Can you combine all three approaches? Absolutely. In complex systems, they often complement each other. Analyze your desired feature and determine which type of global is most applicable to it. This gets easier the more you develop.
4. Are global fields saved on server-hosted files? Only if set in single-user mode or during scripted server-side operations. If you set global fields with values and host the open file, it will retain those global values. This is an outdated practice, though. It is better to manage default values through scripting.
5. How do I enforce one record in a global table? Use a startup script to check and delete excess records or apply validation rules. Use the file script trigger to open the first window and verify that the global table has a single record and is initialized.