Global field calculations and multi-user concerns

Expert

Understand how global fields behave in calculations on FileMaker Server, why each connected user has their own global value, and how to design around multi-user global field limitations.

What you'll learn

How global fields are session-scoped on FileMaker Server
Why calculations referencing globals are always unstored
How to use globals for per-user calculation inputs safely
Alternatives to globals when a shared value is needed

Global fields in FileMaker hold a single value per user session. On FileMaker Server, each connected client has its own copy of every global field. This makes globals ideal for user-specific state (current filter, session preference, logged-in account name) but unreliable for any value that must be shared across users. Calculations that reference globals are always unstored -- which has performance and findability implications.

1/4

Global field session scope

On FileMaker Server, every client connection gets its own copy of every global field. Changes to a global by User A are invisible to User B. The global resets to its defined default value at the start of each new session.

FileMaker Script

// Globals are session-scoped on Server:
// User A sets Globals::gFilter = "Active"
// User B's Globals::gFilter is still "" (or its default value)
// User A's change does not affect User B

// Correct use of globals -- per-user state:
Set Field [ Globals::gCurrentUserId ; Get ( AccountName ) ]
Set Field [ Globals::gDisplayCurrency ; "USD" ]

// Wrong use of globals -- shared app state:
// If you set Globals::gAppVersion in a script, only the current user's
// session sees it -- other users are unaffected

Calculation field as index key: tradeoffs Calculation debugging techniques