Architecture, modules and roles

This page summarizes Omniscol's application architecture and the roles visible on the school side. Precise contractual commitments (availability, backups, retention, monitoring) belong to the approved legal or commercial documents.

Hosting and reliability

Omniscol is hosted in the European Union, more specifically on AWS Paris and Scaleway Paris. The product uses backup, monitoring and logical isolation mechanisms between school accounts; the details applicable to an account depend on the contract and the environment concerned.

See FAQ — Security and hosting for the user-facing details.

Software architecture

• Web application: the application loads once, then the screens are rendered dynamically with REST/JSON exchanges (Single Page Application).
• CouchDB as the main database.
• Redis as the database for application-side synchronization and logs.
• TypeScript for the interface (webapp).
• Node.js / Express backend orchestrating the internal engines (api, webapp, portal, panel, ical, mcp, oauth2, etc.).
• C++ for the generation algorithm, run on dedicated VMs started on demand.

Security

• HTTPS for exposed communications.
• Cloudflare as the exclusive entry point (anti-DDOS protection).
• Passwords pre-hashed client-side with scrypt, then re-hashed and salted server-side. They are not stored or transmitted in plain text.
• JWT authentication with signing keys and a short lifetime; a key rotation or revocation can invalidate signed tokens.
• Sharing links — signed, expirable, tied to the account that generated them and invalidated by a password change or deactivation of that account.
• API tokens with a root key and derived tokens, endpoint scopes and expirations.
• OIDC / SSO available depending on the contract and the account's configuration.
• JSON export and internal backups for data reversibility.

User roles

Omniscol distinguishes several roles on the school side:

The mapping between these labels and the technical role identifiers is detailed in Users and roles.

A single user can hold several roles at once. For example, a teacher who takes part in planning can be both Teacher and Administrator.

The Sharing link role does not correspond to a regular user account. These are signed links: timetable web links are read-only, while some targeted links can allow a limited action, such as entering a teacher's availability until an expiration date.

There are also internal roles reserved for Omniscol's teams: platform administration, translation, sales operations and reseller partners. Some of these accounts are allowed to sign in to school accounts, for maintenance purposes. They then act as superadministrators of the school, with more capabilities than an administrator: importing raw data into the database, enabling or disabling paid options, signing in on behalf of a user. These accesses trigger visible login alerts and their tokens expire very quickly. With great power comes great responsibility.

Modules

The modules visible in a standard account:

• Home (home) — entry page and summary of the day.
• Timetable (schedules) — consultation and one-off changes.
• Dashboard (dashboard) — occupancy and service statistics.
• Absence management (absences) — declarations and substitutions.
• Timetable management (timetables) — building, generating and publishing timetables.
• Administration (admin) — users, settings, import / export and integrations.

Depending on the contract, other modules can appear, notably Staffing for planning pastoral and supervision tasks.

Multi-school

Each school is logically isolated on the server side and accesses its own domain. A school's data is not visible to other schools from the application. However, on request, a communication channel can be enabled between separate accounts, in order to share room and teacher occupancy conflicts. This is very useful for shared buildings, or for a group of schools sharing resources.