Table Occurrence Naming Conventions in Depth

Intermediate

Design a TO naming system that scales to hundreds of occurrences and survives team handoffs, covering prefixes, suffixes, versioning, and documentation.

What you'll learn

  • The components of a robust TO name: table, purpose/modifier, family
  • How to handle utility TOs (globals, constants, helper tables)
  • How to document the naming system in the solution itself
  • Common anti-patterns and how to remediate them

Naming table occurrences (TOs) is one of the most impactful decisions in a FileMaker solution. Bad names ("Table1", "ContactsNew", "FIXED") become permanent fixtures that confuse every future developer. A consistent, documented naming system lets you navigate the graph, understand any TO's purpose at a glance, and confidently refactor.

1/4
1

Name components: table + modifier + family

A TO name has up to three parts: the base table name, an optional modifier describing the filter or role, and the family suffix. Not every TO needs all three parts.

TEXT
// Pattern: [BaseName][_Modifier][_Family]

// Examples:
Contacts                    // anchor, no modifier needed
Contacts_Active             // anchor for a view showing only active contacts
Invoices_Contacts           // buoy: Invoices in the Contacts family
InvoicesUnpaid_Contacts     // buoy: filtered to unpaid invoices, Contacts family
GlobalValues                // utility TO: global fields table
zConstants                  // utility TO prefix 'z' pushes it to bottom of lists

Sign in to track your progress and pick up where you left off.

Sign in to FM Dojo