Synching Offline App Data with Hosted FileMaker

Your users won’t always have a reliable internet connection in many real-world scenarios. It may be necessary for field agents, remote locations, or mobile users to operate in “offline mode” before synchronizing their data with a centrally located FileMaker server. Delivering a seamless offline → online experience is difficult, but it is possible with the correct design and tools.

In this post, we explore:

Why offline sync is important
Common challenges & pitfalls
Approaches & architectures for offline sync in the FileMaker ecosystem
Tools, examples, and best practices

Why Offline Sync Is Important

When your users can’t reliably remain connected:

They cannot access or record data if the host server is unreachable, which hurts productivity.
You risk data loss or delays in operations.
You want continuity: your app should feel “always usable,” whether online or offline.

Offline synchronization lets users work with a local copy (on a mobile or desktop device). Changes they make offline are queued, and when connectivity returns, those changes sync with the hosted server (and server changes can sync back to the local copy).
This model helps ensure continuous operation, even in low- or no-network conditions.

Challenges & Pitfalls When Synching Offline Data

While the concept is straightforward, implementing offline sync brings many complications. Here are key challenges:

Challenge	Description / Why It’s Hard
Conflict resolution	When changes are made both locally and on the server to the same record or field, you need a strategy to resolve which change “wins” or how to merge them.
Data integrity & transactionality	Ensuring that a group of related changes either all succeed or fail together (so data doesn’t get left in a half-updated state).
Initial synchronization	Getting the full dataset down to the local device (or necessary subset) can be heavy, especially with large databases.
Performance over slow networks	Syncing large volumes of data, especially images, containers, or media, can be slow or error-prone on flaky connections.
Schema / version mismatch	If your hosted solution’s schema or logic changes (new fields, tables, script logic), local copies may be out of sync in structure, causing sync errors.
Security & authentication	Local data needs protection (encryption, access controls), and the sync process must authenticate users securely.
Handling deletions / “tombstones”	When records are deleted on one side, you must communicate that to the other side (not just ignore it).
Partial sync / subset data	Usually local copies don’t need the entire database; you must filter which records, relationships, or fields are relevant locally.
Network state changes & intermittent connectivity	Sync logic must handle connection drops, retries, partial uploads, timeout, etc.

FileMaker’s platform does not provide out-of-the-box full offline sync (for example, FileMaker Go and hosted file combinations require additional design). It’s common in forum discussions to see the advice: “Your app is either offline or connected; syncing is complicated, so avoid it if possible.”

Approaches & Architectures for Offline Sync in FileMaker

Here are several common patterns or architectures used by FileMaker developers to handle offline → online sync:

1. Full Copy + Merge (Hub & Spoke)

Local device holds a full (or nearly full) copy of the FileMaker file.
Users make changes locally offline.
When online, sync engine merges local changes into the hosted version (hub).
Also, the server’s changes may sync back to the local version.
Requires conflict detection & merge logic.

This pattern is commonly used by sync tools such as MirrorSync.

For instance, 360Works’ MirrorSync supports hub-and-spoke architecture, smart updates, deferred writes, and optimizations for speed.
In the YWAM case study, MirrorSync was used to synchronize FileMaker Go devices and the hosted server in challenging connectivity environments.

2. Incremental / Partial Sync (Selective Tables & Records)

Only a subset of tables or records, based on location, user, or need, is synchronized.
Reduces data volume and speeds sync.
Local file is lean.
Sync engine must handle “delta changes” (records added/modified/deleted) rather than full copy.

3. Webhooks / HTTP API Upload (Push-only, or mostly one-way)

Local app queues changes as JSON or HTTP payloads.
Once online, local sends data to a server endpoint or webhook receiver.
The server side merges or inserts that data into hosted FileMaker.
Optionally, server can send changes back to local via API or pull.

A good example: using Otto Webhooks with FileMaker Go + hosted server to manage offline-to-online data flows.

4. Using a Middleware or Sync Engine

Use a third-party sync engine or middleware (e.g. MirrorSync, LiveCode for FM, custom sync services).
These tools often handle conflict resolution, batched sync, transaction safety, and sync scheduling.
The developer focuses on business logic and mapping rather than low-level sync plumbing.

LiveCode for FM, for example, describes its solution by saving data locally when offline, then syncing when connection returns.

5. Snapshot / Export-Import Approach (Simple, limited cases)

When going offline, export the relevant data (e.g. to a container or file).
Work locally on that snapshot.
When back online, import changes back into the hosted version.
This is simple but often brittle, especially with edits in both copies.

FileMaker’s native “Import Records” mechanism can support limited record-level syncing, but it’s often unsuitable for ongoing, multi-user sync scenarios.

Steps to Design & Implement Offline Sync in FileMaker

Below is a suggested process (which can be adapted according to your context):

1. Define Use Cases & Scope

What parts of your data need to be available offline (tables, fields, relationships)?
Will users edit, create, delete records locally?
Do you need bidirectional sync, or only local → server?
What is acceptable latency?
How to handle conflicts?
What network environments will users operate in (rural, low bandwidth, spotty coverage)?

2. Versioning / Schema Management

Ensure all sync-aware tables have fields for creation timestamp, modification timestamp, UUID, sync status flag, and deletion flags (“tombstone records”).
Plan version control, so when you update your hosted schema/app logic, local files remain compatible.

3. Choose or Build Sync Engine

Use an existing sync engine when possible (e.g. MirrorSync, LiveCode for FM, custom).
If building custom, develop scripts that can:
1. Identify local changes (new, modified, deleted).
2. Batch those changes and send to the hosted server.
3. On the server, apply those changes (insert, update, delete) respecting constraints.
4. Send back changes made on server to local, and merge.
5. Handle conflict resolution (based on timestamps, user priority, or manual prompts).

4. Sync Scheduling & Triggering

Decide when sync should run: manual button, periodic (every 5, 10 min), automatic when connection is re-detected, or user-initiated.
Use retry logic in case of partial failures or timeouts.
Use incremental sync (only changed records) to minimize data traffic.

5. Conflict Resolution Strategy

If the same field was changed locally and on the server, choose a “winner” (latest, or server priority, or ask user).
If related records are changed, ensure referential integrity.
Log conflicts and provide UI for users or admins to resolve manually when necessary.

6. Optimize for Performance

Sync only needed fields and records.
Batch operations to avoid many small API calls.
Compress or optimize container data (images, files) if possible (e.g. upload separately).
Use server-side operations (FileMaker Server scripts) to process bulk changes rather than client scripts.
Use “smart updates” (only changed fields) rather than rewriting entire records. MirrorSync offers performance optimizations like Smart Updates, deferred flushing, etc.(360Works)

7. Testing & Validation

Test in real offline-to-online environments.
Change same record in both places to test conflict logic.
Test large data sets, high-traffic syncs.
Test schema changes and updates over time.

8. Deployment & Maintenance

Monitor sync logs, errors, conflict frequency.
Provide means to force sync or manual reconciliation if problems arise.
When updating the hosted app schema or logic, push updates to local files (with versioning) in a way that doesn’t break sync.
Periodically archive or purge old data to keep both hosted and local data sets manageable.

Example / Real Use Cases

In the YWAM (Youth With A Mission) medical ship scenario, MirrorSync was used to sync FileMaker GO, FileMaker Pro, and FileMaker Server across remote and cloud environments.
Otto Webhooks + FileMaker Go was used to push offline-collected data to hosted server when reconnected, enabling seamless transitions.
SeedCode / DayBack / GoZync frameworks have demo patterns for offline sync in FM Go, with push/pull models.

These real cases show that offline sync in FileMaker is not just theoretical — it’s actively used in mission-critical, remote workflows.

Best Practices & Tips for Success

Keep local files minimal: only necessary tables, fields, relationships.
Give priority to schema stability — avoid frequent structural changes.
Use universally unique IDs (UUIDs) for records to avoid primary key collisions.
Maintain a “sync status” flag on each record (e.g. unsynced, syncing, synced, failed).
Always log sync operations (success, failure, time, user).
Provide UI feedback to users: “Sync in progress,” “Conflicts to resolve.”
Design for idempotent operations (so retrying doesn’t do harm).
Test in weak-connection and offline scenarios.
Plan for schema migration: e.g., version checks, fallback logic.
Encrypt sensitive local data if needed.
Monitor and manage container data (images, files) — large containers are heavy to sync.
If possible, defer heavy container sync to times of good connectivity only.

Conclusion

Synching offline app data with a hosted FileMaker solution is a powerful way to give your users uninterrupted functionality even when connectivity is spotty or unavailable. However, it’s a technically complex problem with many moving parts: conflict resolution, performance, schema evolution, error handling, and design trade-offs.

By carefully scoping your needs, choosing a robust sync engine (or building a custom one), using standard patterns (hub & spoke, incremental sync, webhooks), and following best practices, you can build a sync solution that is reliable, maintainable, and user-friendly.