Check a FileMaker attachment before accepting it

Example status

Native attachment selection and failure-path checks passed

Scope and what still needs checking

FileMaker Pro desktop, using GetContainerAttribute (introduced in version 13). This is a metadata check, not malware scanning.

FileMaker Pro 26.0.3: empty/text candidates, embedded metadata, accepted-file preservation after rejection and cancellation, misleading extension, exactly 5 MiB accepted and 5 MiB plus one byte rejected. Test binaries were created with Base64Decode inside the laboratory. Follow-up checks used the native picker for a verified zero-byte file and a reference-only fixture, then checked picker Cancel, native error 301 on a locked save, retry after unlocking, and error 511 from a forced field-size validation. Failed saves preserved the accepted file. An ordinary candidate field with managed secure external storage passed and persisted after close/reopen.

Local Full Access evidence; open external storage and the intended restricted account were not tested. Global container fields cannot use managed external storage: the secure-storage case used an ordinary isolated review record. The lab’s 1 KiB accepted-field limit was an injected test constraint, not the article’s 5 MiB policy.

Readable script fragments must be recreated in Script Workspace. Pseudocode describes a design, not an executable script. Use a disposable working copy.

Get the review data and expected results ↓

Keep a proposed attachment separate from the accepted one

A person chooses a file for an order, but the container might hold text, an old file reference, or something too large for your workflow. A small review step can explain the problem before the attachment becomes part of a business record.

Use a candidate container in a review area. Keep the existing accepted attachment untouched until the candidate passes your policy and the person confirms Save. Cancel should discard only the candidate. Do not use a validation experiment to replace a real supplier document.

Read three useful attributes

Readable FileMaker script · inspect the candidate

Set Variable [ $name ; Value: GetContainerAttribute ( Review::Candidate ; "filename" ) ]
Set Variable [ $bytes ; Value: GetContainerAttribute ( Review::Candidate ; "fileSize" ) ]
Set Variable [ $storage ; Value: GetContainerAttribute ( Review::Candidate ; "storageType" ) ]

The filename is a useful label, fileSize reports bytes, and storageType distinguishes embedded content, externally stored content, references and text. An unavailable or unexpected attribute is a reason to stop and explain the problem, not to assume the candidate is safe.

For this teaching policy, accept embedded or managed external files no larger than 5 MiB (5,242,880 bytes). Reject references and text. Your actual storage policy may be different; make it explicit before writing the check.

Return one actionable reason

FileMaker calculation · proposed metadata policy

Case (
    IsEmpty ( Review::Candidate ) ; "Choose a file." ;
    not ( $storage = "Embedded" or
          $storage = "External (Secure)" or
          $storage = "External (Open)" ) ; "Insert the file itself, not text or a reference." ;
    IsEmpty ( $name ) or IsEmpty ( $bytes ) or $bytes = "?" ; "The file metadata could not be read." ;
    GetAsNumber ( $bytes ) <= 0 ; "Choose a nonempty file." ;
    GetAsNumber ( $bytes ) > 5242880 ; "Choose a file no larger than 5 MiB." ;
    "Ready for review."
)

Evaluate this after reading the three attributes in the same script. Keep “Ready for review” distinct from “Saved.” Your accept action must recheck the candidate, copy it to the intended record, capture the save error and report success only after the save succeeds.

A filename is not proof of file content

Renaming a text file to invoice.pdf does not make it a valid PDF. An extension allowlist can improve the user experience, but it cannot establish content safety or scan for malware. If you need content verification, add an appropriate inspection service or controlled processing step with its own privacy and failure rules.

A global candidate container is convenient for a session-local embedded-file review, but FileMaker does not allow global fields to use managed external storage. To check that storage mode, use an ordinary candidate field on an isolated review record and define who owns that record. Do not silently make one shared candidate record serve several people.

Likewise, an externally stored container is not automatically a broken reference. FileMaker-managed external storage and a reference to an arbitrary filesystem location are different cases. Test the actual storage setup and the account that will use it.

Exercise selection, rejection and cancellation

On a small screen, scroll the table sideways to see every column.

Candidate	Expected policy result
Empty container	Choose a file
Small embedded file	Ready for review
File over 5 MiB	Rejected with size explanation
Text or file reference	Rejected with storage explanation
Renamed non-PDF under limit	Metadata may pass; no claim that it is a PDF

Then replace a rejected candidate with an acceptable one, cancel with an existing attachment present, and simulate a record lock while saving. The accepted attachment must remain unchanged after Cancel or a failed save. The review pack includes a tiny text file and instructions to construct an oversized fixture.

This pattern could be added to document workflows such as Purchase Desk or Project Delivery. It is a customization idea, not a claim that those products currently contain this exact validation policy.

Try the small review fixture

The fictional data and review notes below accompany this article. They are not a FileMaker application, and they do not establish native test results.

References

Documentation checked on 21 October 2026. This review does not establish native execution or hosted compatibility.