Unused elements

Last updated 2026-08-16

Every long-lived solution accumulates ballast: fields nothing reads, scripts nothing calls, occurrences nothing looks through. The Unused page surfaces it, with a design bias you should know about up front: FM Fathom would rather miss a deletion candidate than tell you something is safe to delete when it isn't.

What gets flagged

Four categories, each with its count: dead fields, unused table occurrences, orphan scripts, and unused value lists. An element is flagged only when nothing in the parsed solution references it, and the criteria account for indirect roles. One example: a table occurrence that no field or portal shows can still be load-bearing because a relationship path travels through it, and FM Fathom treats occurrences on a traversal path as used.

Check it against production

With server logs uploaded, the Server Side Usage view adds the second opinion: is this "unused" script actually running in production anyway (a schedule, an odd entry point)? Structure says one thing; logs confirm or veto it.

The workflow

  1. Start with the category you know best; you'll calibrate fastest where you can sanity-check the flags yourself.
  2. Ask why. Each flag carries its evidence, and you can ask the AI to explain any item's status.
  3. Put real candidates on the board, assign them, and burn the list down deliberately.
  4. Verify in FileMaker before deleting. FM Fathom sees the export; only you know about that one integration that calls a script by name from outside.

Related