Preview a FileMaker bulk update before applying it

Make the action understandable before it changes data

Imagine assigning a new owner to three open tasks. The person should see which tasks will change and the old and proposed owner. “Update found set” is too vague if the found set can change between preview and Apply.

This example updates only an OwnerID on existing tasks. It does not delete records, rewrite arbitrary fields or operate on an entire database. Begin with a disposable copy, a stable task key and a documented rule that completed tasks are ineligible.

Save a plan, not a record count

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

Store a batch ID and one immutable record ID per row, plus the expected old value and proposed value. A modification counter or revision field can help detect other changes if your application maintains it consistently. Do not substitute record position for record identity.

The preview screen should show selected rows, exclusions and the proposed owner’s name alongside its ID. Let the person remove a row or cancel the whole plan before any business record is edited. A changed plan requires a fresh review.

Recheck each selected record

For each approved plan row:
    If a committed result already exists for this batch and row:
        Show that result; do not apply it again.
    Open a transaction in the worker window.
    Locate the task by its immutable ID within authorized scope.
    Open the task for editing and check the lock result.
    Re-read owner, completion state and expected revision.
    If eligibility or expected values changed:
        Revert and record a skipped reason.
    Otherwise set the new owner.
    Save the success receipt in the same transaction.
    Commit and inspect the commit error immediately.
    On failure, report failure and confirm no task change survived.

This example chooses partial completion: one record can succeed while another is locked or changed. It is not an all-or-nothing batch. State that policy on the preview. If the business requires all rows together, use a different transaction design and a realistic locking strategy.

Keep writes and their success receipts in the same transaction and originating window. Enforce uniqueness of the batch/row receipt and prevent concurrent workers from applying the same plan. A button disabled in one window does not provide that guarantee.

Separate saved, skipped and failed

After preview, change TASK-02’s owner in another session and lock TASK-03 there. Apply the plan: TASK-01 should save; TASK-02 should be skipped because its expected value changed; TASK-03 should fail with a lock explanation. Report one saved, one skipped and one failed, with record links for review.

Capture FileMaker errors immediately after the operation they describe, including commit. Do not use the fact that a loop finished as evidence that every write succeeded. A failed audit receipt must not leave an unreported successful change.

A repeat click should return the existing success for TASK-01. Failed or skipped rows need a newly reviewed retry plan, rather than automatically applying later to changed data.

Try the cases that change the outcome

Test an empty selection, Cancel, changed found set, changed owner, completed task, missing record, validation failure and a restricted account. After every failed attempt, inspect the actual OwnerID and receipt table. Verify the two together.

For the first native review, keep the fixture tiny and inspect every result manually. The separate native laboratory now covers the frozen preview, Cancel, changed-input guards, partial results, repeat actions, result navigation and fresh retries, as well as worker replay and rollback. See the example status above for the remaining permission and hosted-concurrency checks. The laboratory is a synthetic test fixture, not a customer download.

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.

• bulk-update-plan.csv
• bulk-tasks.csv
• Expected record IDs and counts (JSON)
• Setup and native review instructions

References

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

• Open Transaction
• Commit Transaction
• Open Record/Request