A common question from FileMaker developers building integrations is: “Can I lock a record through the Data API or OData, and have that lock show up for everyone using the database?”
This article reflects my personal understanding as of today, and I may be missing details or newer capabilities. My hope is that it opens a discussion. Record locking is a critical issue for rich FileMaker integrations, especially as more sophisticated user interfaces move into WebViewers, where the coordination between the UI and the database becomes harder to get right. I’d welcome corrections, experiences, and alternative approaches from others who have solved this in practice.
By now according to my knowledge, the short answer to the question is no. Understanding why points toward a workable solution.
Why native locks don’t work here #
FileMaker’s native record locking belongs to a client that has a record in edit mode. The lock lasts only as long as that client is editing, and FileMaker Pro, Go, and WebDirect are the only clients that hold one.
The Data API and OData are stateless. Each request stands alone, and a script run through the Data API finishes when it returns. Nothing stays locked afterward, and neither API has a “lock this record” endpoint. There is also no built-in way for FileMaker Server to broadcast a lock to connected clients.
The solution: a soft lock stored in the data #
A soft lock is an ordinary record in your table that every client agrees to respect. It has three fields:
lock_user, the person holding the locklock_session, a unique token for that holder’s sessionlock_expires, a timestamp that the holder keeps renewing
Acquire the lock in a script. Expose a server-side script to the API. It finds the record, checks whether an unexpired lock belongs to someone else, and only then writes the new lock. The find, check, and write run inside one script, which narrows the race window, but it doesn’t close it. Two scripts running at the same moment can both read “no lock” before either writes. The script returns JSON, so the API client can tell whether the lock was granted.
Renew and release. The client calls the same script every 30 to 60 seconds to push lock_expires forward. A separate release script clears the fields when the user saves or leaves the record. If a client crashes, its lock simply expires, so a record can’t stay locked forever.
Make FileMaker users see it. FileMaker Server doesn’t push changes to clients, so FileMaker Pro clients have to poll. An Install OnTimer Script call on the layout can run every 10 to 30 seconds, check for an active lock held by someone else, and make the editable fields read-only with a banner. Native locking still protects Pro users who are editing at the same moment.
Caveats #
A soft lock is advisory. Any script or API client that ignores the lock fields can still write to the record. Enforce the check inside the server-side scripts that perform writes, not only in the user interface.
Polling adds latency. A change can take up to one timer interval to appear on a FileMaker screen.
Instant push needs something else. To notify a non-FileMaker application immediately, you need a separate mechanism, such as a webhook called from a script step or a small service that watches the lock table.
Expiry needs care. Choose a time-to-live that is longer than your renewal interval, or locks will lapse during normal use.
Can a server-side script lock a field? #
It’s tempting to think a script could put a specific field of a specific record into edit mode, taking focus with Go to Field, and so hold a native lock. In practice this doesn’t work from a server-side script. Native locks belong to an interactive client with a window. A script running on the server has no window, so UI steps such as Go to Field have no reliable effect. Even if focus were set, the script ends by committing or reverting, which releases the record, and the Data API can’t keep an edit session open across requests.
Transactions #
FileMaker doesn’t provide an explicit BEGIN and COMMIT across several script steps or several requests. Commit Records/Requests is atomic for the records it saves, but nothing keeps a multi-record transaction open between API calls. Check the documentation for your FileMaker version before relying on any transaction-like behavior.
Stronger protection with optimistic concurrency #
A soft lock prevents two people from starting to edit the same record, but it can’t stop a race. Optimistic concurrency addresses the more common problem, which is one user overwriting another’s change. The Data API returns a modId for each record. The client sends the modId it last read with its update:
PATCH /records/{id} { "fieldData": {...}, "modId": "42" }
If the record has changed since that modId was read, the request fails. The client then reloads the record and retries. This doesn’t stop anyone from opening a record, but it prevents silent overwrites. For a stricter guarantee, serialize lock acquisitions through a single dedicated lock record or a server-side queue, though that adds complexity most solutions don’t need.
Takeaway #
You can’t trigger a native FileMaker lock from the Data API or OData, but a soft lock built from a few fields, a few scripts, and a polling timer gives you coordinated editing across API and FileMaker clients. Treat it as a coordination tool rather than a security control, and make sure the server enforces it.