Enterprise SyncNative: Encrypted Operational Collaboration at Organization Scale
A use case for warehouses, factories, research organizations, multi-site operations, and larger crews
The Operational Problem
In a larger organization, inventory location is not only a convenience issue. A delayed or overwritten update can stop work.
A warehouse employee moves a calibrated tool to another zone. A laboratory technician transfers equipment to a shared cold room. A maintenance crew consumes the last spare component. Other workers need that change quickly, but the organization may not want its operational inventory stored as plaintext in a vendor database.
Enterprise SyncNative addresses both requirements:
- local-first operation and fast encrypted event synchronization;
- zero-knowledge handling of workspace content;
- organization-level membership and administrative controls;
- checkpoint-based recovery for authorized devices.
Example: A Multi-Site Maintenance Operation
An industrial maintenance company has three sites and several crews.
The company creates an Enterprise organization and separate workspaces for:
- Central Warehouse;
- Site A Tooling;
- Site B Spare Parts;
- Mobile Crew Equipment;
- Calibration and Inspection Assets.
The organization owner is the Enterprise admin. The admin invites employees through Sortify's existing invite-link or join-code flow, approves access, assigns workspace membership, and can suspend, reactivate, or remove organization members.
Employees continue to work from the same Sortify app. Enterprise workspaces are tagged clearly and appear alongside personal workspaces in Home and Search, while the Enterprise workspace area exposes organization-specific management.
How an Update Moves
When a technician moves an item:
- The change is committed to the local SQLite database.
- The local change journal records the operation and actor identity.
- Sortify creates a compact managed-sync event.
- The event and its conflict metadata are encrypted with the workspace key.
- The encrypted event is written to the Enterprise Firestore namespace.
- Authorized active devices receive the event through the workspace listener.
- Each device decrypts, validates, and applies the change locally.
- Activity and item history identify the member by the synchronized workspace-member identity record.
The current conflict layer includes pragmatic field-level protection for common item updates and moves. It is not marketed as a complete CRDT implementation. The architecture can evolve without replacing local SQLite or the existing provider-based sync engines.
Organization and Workspace Roles
Enterprise separates organization membership from workspace membership.
This matters because removing an employee from one workspace should not automatically remove them from the entire organization.
The implemented model supports:
- an organization owner/admin;
- organization member records;
- workspace owner and member roles;
- workspace-level invitations and removals;
- organization-wide suspend, reactivate, and remove actions;
- propagation of organization status changes to affected Enterprise workspace memberships;
- safe audit metadata for administrative actions.
The organization owner cannot be removed through a generic member action. Enterprise-wide actions remain deliberate and separate from ordinary workspace settings.
What the Managed Infrastructure Can See
Firebase/Firestore can hold coordination and security records such as:
- organization, workspace, member, and device IDs;
- roles and account status;
- event sequence numbers;
- sync cursors;
- checkpoint generations;
- timestamps;
- encrypted event payloads;
- encrypted checkpoint payloads;
- encrypted key envelopes;
- entitlement and administrative audit flags.
It must not hold plaintext inventory fields such as:
- item or room names;
- exact locations;
- quantities or notes;
- barcodes or serial numbers;
- photo content;
- decrypted database snapshots;
- plaintext workspace or account master keys;
- recovery passwords.
This gives the organization managed collaboration without giving MokingBird readable access to its operational inventory.
Recovery and New Devices
Enterprise recovery avoids replaying an unlimited event history.
- The employee signs in.
- Sortify verifies active organization and workspace membership.
- The device unlocks the encrypted key envelope using the applicable user-held secret or trusted-device flow.
- The latest encrypted workspace checkpoint is downloaded and decrypted locally.
- The retained event tail is applied in sequence.
- The local SQLite workspace becomes the working copy.
Checkpoint compaction limits long-term event storage and recovery reads. Old events can be removed after a checkpoint safely covers them while a retained tail supports active-device convergence.
An organization admin can control membership status, but cannot bypass the zero-knowledge key boundary to read or recover plaintext workspace content.
Cost and Reliability Controls
Enterprise SyncNative is designed to avoid treating Firestore as the app's primary UI database.
Cost controls include:
- local-first reads and writes;
- compact encrypted events rather than full database uploads;
- listeners scoped to relevant workspaces;
- offline queues and retry backoff;
- encrypted checkpoints;
- event and checkpoint compaction;
- safe metadata rather than duplicated plaintext content;
- entitlement and membership checks before managed access.
The production deployment still requires validated Firestore security rules, indexes, App Check configuration, monitoring, and multi-device runtime testing.
Relationship to Other Sortify Modes
Enterprise SyncNative is isolated from existing modes:
- local-only workspaces remain device-only;
- solo cloud workspaces keep encrypted snapshot/package sync;
- Google Drive, OneDrive, and Dropbox collaboration remain available;
- Sortify Cloud serves entitled non-enterprise managed collaboration;
- Enterprise uses a separate organization namespace and administration model.
The new architecture is added on top of Sortify's existing local-first foundation. It does not force personal or provider-based workspaces into Enterprise behavior.
Availability and Commercial Terms
Enterprise workspace creation requires the Enterprise entitlement or an authorized test override. Production availability depends on backend deployment, security configuration, billing or contract setup, and the support terms agreed with the organization.
Enterprise enquiries: [email protected]
The Result
The maintenance company gets faster shared operational state, organization-level control, and recoverable encrypted workspaces. Employees keep working locally. Firebase transports ciphertext and coordination records. The organization does not have to choose between usable collaboration and a zero-knowledge privacy boundary.