OnObjectValidate or OnObjectSave: which FileMaker trigger should I use?

Validate before acceptance; react after the object saves

Use OnObjectValidate when you need to check changed field input before FileMaker validates and saves the active object. Use OnObjectSave for a reaction after that object’s data has passed validation and saved, before the field is exited.

Neither name means “the entire record has now committed.” Keep database validation and your controlled Save procedure responsible for durable data rules. A UI trigger is a useful place for feedback, but it is not a universal gate for every way data enters the file.

Know what returning False does

Both triggers activate for changed field data. Returning False from OnObjectSave is not an undo operation. Claris describes these details in the OnObjectValidate and OnObjectSave references.

Watch one field’s events

In a teaching copy, place Contacts::FullName on a form. Create a script named Trace field event and attach it to OnObjectValidate and OnObjectSave, passing the trigger name as a text script parameter. Use a session variable so the trace itself does not create a database write.

Set Variable [ $$fieldTrace ; Value: List (
    $$fieldTrace ;
    Get ( ScriptParameter ) & " | record state=" & Get ( RecordOpenState )
) ]
Exit Script [ Text Result: True ]

Clear $$fieldTrace before each test. Change the name and Tab out. Under ordinary successful field exit, expect Validate before Save. Repeat without changing the value; these two triggers should not add new entries merely because the field was visited.

The record-state value is diagnostic context, not proof of a successful final commit. Do not write “Saved successfully” to the user solely because this trace reached OnObjectSave.

Add a narrow input check

For a simple FullName field, this OnObjectValidate example rejects an all-space value. Attach it only in Browse mode. It is feedback for this object, not a complete name validator.

If [ IsEmpty ( Trim ( Contacts::FullName ) ) ]
    Show Custom Dialog [ "Name needed" ; "Enter a name before leaving this field." ]
    Exit Script [ Text Result: False ]
End If
Exit Script [ Text Result: True ]

Keep the field active so the person can correct it. Avoid adding unrelated navigation, committing other records or recursively rewriting the same object in this trigger. If the field also appears in Find mode, do not force a user to enter a name just to search for empty values.

Check the write paths that bypass the object

Imports and other operations that work on underlying data do not necessarily activate layout-object triggers. Claris lists these distinctions under actions that do not activate script triggers. An object rule must not be your only protection for required business data.

Use appropriate field validation, privilege settings and controlled write scripts for your actual import, API and user-entry paths. Do not infer coverage from a trigger’s product compatibility table; an available script engine does not mean every external write generates an object event.

Test changed valid input, unchanged input, a rejected value and a deliberate False from OnObjectSave. Then inspect what happens when a script or import changes the same field without editing the object. Record the difference before relying on the rule.