The Anchor-Buoy Method
IntermediateMaster the anchor-buoy layout pattern for organizing the relationship graph -- the industry-standard approach to keeping FileMaker graphs readable and maintainable at scale.
What you'll learn
- The core rule: buoys connect only to anchors, never to other buoys
- How to name anchors and buoys consistently
- How to determine when to create a new buoy vs. reuse an existing one
- How the anchor-buoy layout corresponds to layout-per-context design
As a FileMaker solution grows, the relationship graph becomes an unmaintainable tangle of crossing lines. The anchor-buoy method, popularized by Wim Decorte and others in the FM community, organizes table occurrences (TOs) into families: one "anchor" TO per table that owns the context, and "buoy" TOs connected only to the anchor. No buoy connects to another buoy. The result is a grid-like graph that scales to hundreds of TOs without becoming illegible.
Anchor and buoy defined
An anchor is the "home" table occurrence for a layout -- it provides the context for that layout. Buoys are additional TOs of other tables (or the same table) connected to the anchor, used to access related data on that layout. One layout = one anchor = one family of buoys.
// Contacts layout family: // Anchor: Contacts // Buoys connected to Contacts: // Accounts_Contacts (the account this contact belongs to) // Activities_Contacts (activities related to this contact) // Invoices_Contacts (invoices for this contact) // The key rule: Accounts_Contacts does NOT connect to Activities_Contacts. // All lines go through the anchor.
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo