Odoo 19 documentation describes an offline mode for users who are already logged in when coverage becomes unreliable or disappears. Views and records previously opened online can be reopened. That can help on a train, in a poorly covered warehouse or at a customer site, but it is not a complete ERP operating without a network.
The central limitation is straightforward: prepared data remains readable but cannot be modified offline. There is no general deferred-entry facility or standard queue that replays every operation once connectivity returns. A company should treat this feature as degraded read access, not as a complete business-continuity plan.
What Odoo 19 actually makes available
Odoo stores locally the views and records an authenticated user has already opened. To prepare for connectivity issues, the documentation advises briefly opening the required items while online. Scope therefore depends on recent activity and user preparation; the database is not automatically replicated.
Odoo caps offline data at 2 GB for performance reasons. When the limit is reached, the oldest data is removed to make room for recent activity. This is a technical envelope, not a guarantee that a particular business list will always remain available.
A hard browser refresh using Ctrl + F5 or Cmd + Shift + R removes locally stored data. A routine troubleshooting gesture can therefore erase offline access just before travel. Support instructions should state this consequence clearly.
Read-only access: useful scenarios and false expectations
The mode may help a salesperson reread a customer record they prepared, a project manager retrieve a previously opened file, or a technician consult preloaded intervention details. The official source does not, however, promise offline quotation creation, delivery validation, time entry or field-service completion.
Teams should distinguish a brief interruption, an area with weak coverage and a prolonged outage. Local viewing reduces friction in the first two cases. In the third, dependencies on authentication, attachments, integrations, payments, printing and server-side processing require a genuine recovery plan.
Custom modules: test rather than extrapolate
Odoo states that offline access is supported for apps and modules built with standard Odoo framework components. This calls for explicit testing of custom developments: bespoke views, JavaScript widgets, controller calls, lazily loaded content and external integrations may behave differently.
An Odoo 19 migration should not mark offline access as validated after testing one standard record. The acceptance matrix must map each field role to the views, fields, attachments and customisations it requires. Gaps may require configuration, an adaptation, or a documented business fallback.
Belgium and France: secure field usage
Maintenance teams, mobile salespeople, depots, construction sites and industrial facilities in Belgium and France all encounter uneven coverage. The useful unit of analysis is not the country but the operational journey, device and actual network quality.
Local retention also requires device rules. Shared workstations, personal devices and lost terminals do not carry the same risk. Companies should maintain screen locking, encryption, device management, access revocation and leaver processes; offline mode does not replace Odoo security controls.
Underside analysis: design a degraded service level
We recommend defining what users must be able to read, what they may record through a controlled fallback, and what must wait for connectivity. This prevents a vague “offline mode” promise from turning into duplicate entry, decisions based on stale information or untraceable workarounds.
A useful test runs on the actual devices with the selected browser. The user logs in, opens the dataset, disconnects every network, closes and reopens the required views, and checks readability. They then test reconnection, information freshness and file limitations. The scenario should be replayed after an Odoo or custom-module update.
Validation protocol
- Identify roles exposed to outages and the information they cannot work without.
- Separate reading, entry, approval, printing and synchronisation requirements.
- Preload representative views and records on each device type.
- Actually disable Wi-Fi and mobile data, then reopen expected content.
- Test custom modules and data loaded from external services.
- Verify attachment behaviour with volumes close to real usage.
- Document hard-refresh impact and the actions support may use.
- Provide a fallback channel for operations requiring immediate write access.
This validation complements an Odoo audit, Odoo migration planning and post-go-live support. Standard functionality may be sufficient for prepared read access; a complete offline workflow needs analysis and, where justified, a dedicated architecture.
Official source
Underside helps companies scope, migrate and secure Odoo. For mobile teams, the goal is to test the service that genuinely remains available during an outage and organise the operations that still cannot run offline.