The idea here is to make use of the offline-first nature of the architecture for a few distinct but related purposes, list below. Demo Mode is part of the larger architectural concept around Onboarding for both customers and [contributors](8-Hour Contributor).

Traditional SAAS offering have infrastructure overhead to support trials of a system. However, the offline-first architecture allows us to offer a demo mode of the system that allows potential "customers" to test the functionality using only offline storage.

Most enterprise data systems require the use of a separate "sandbox" instance where users can enter data into the system for the purposes of either learning, re-learning, or teaching a given feature or function. Again, the offline-first nature of the system gives us a way to support a "training mode" in production systems by use of the demo architecture.

As code contributors on board with the system, the burden of demo data for the purposes of development and testing becomes more and more problematic. The demo mode includes a set(s) of development demo data, that not only is meant to help train users of the system but can help train developers who need to learn the business functions of the app.

The idea here is that the global demo system (currently beta.hospitalrun.io) would always be running in demo mode and as users determined that they wanted to provision a

The notes on the conceptual architecture for moving into Demo Mode are described here.

Additionally, there are a few distinct technical components to the Demo Mode

The current system is compromised of two databases, a user and main, where main contains the data and user contains the login credentials and permission structure. In demo mode, main would be replaced (in access not existence) by a structural clone with revisioned data (probably called demo).

Demo mode can only access the demo database. As such, there's no need for authentication. Furthermore, we want to allow the ability for a demo user to simply reconfigure (via a drop down in the top of the screen) which role they are acting as in the demo system.

Offline-only system that includes, editable, pre-loaded demo data in an offline demo database. This information can be updated as often as their is a production release of the system. Demo mode contains no authentication and the ability to flip between authorization roles for the purposes of demonstrating and training. Demo Mode is always available, even in a production system (again, for the purposes of training), and the features in demo mode are consistent to the pre-configured roles with one exception. If HospitalRun is in demo mode and is not associated to a specific production instance, a Trial may be initiated.

This is a temporary state of the application that is initiated from Demo Mode when a production system is not already associated to it. Trial Mode is initiated through an in-app setup process that creates an (essentially) empty production database that is itself completely offline and awaiting the connection to a production system. Users may setup their own data in this system while they await approval / access to a production instance. Once the production instance is initiated, the data from a Trial can be conditionally synced to the production system.

The greatest difference between trial and production is that a truly deployed HospitalRun system is defined as one that has a (presumably cloud) production server backing it.

A Production system is defined as an instance of HospitalRun that exists on the managed (cloud) infrastructure of HospitalRun and is attached to one or many web clients. A production system has a server-based production database and is being actively supported by the HospitalRun project.