Run only the parts your site actually uses
OgmaQ is built as modules. A workspace switches each one on or off in Administration, and the product it presents changes with it — the sidebar, the command palette, the start-page choices, the sections of a record. What a switch never changes: who may do what, and what a record already holds.
One product, composed for your site
Two sites of the same company rarely work the same way. One runs a formal triage meeting; another routes on the floor. One reviews batch records in OgmaQ; another does not review them here at all. A module is how that difference is expressed — without a fork, a second codebase, or a feature nobody asked for cluttering the screen.
A named part of the product
Each module is one recognisable capability — a destination in the sidebar, or a section that appears on every record. They are listed in one place, described in the product's own words, and there is exactly one switch per module.
Switched per workspace
An administrator sets it once for the company in Administration → Modules. It is not a per-browser preference and not a per-person setting: everyone signed in to that workspace sees the same product.
Reversible, and never destructive
Switching a module off hides its surfaces. Records that already carry its data keep it and still show it, and switching the module back on brings the surface back with the work intact.
Nine modules, each with one switch
Every module ships switched on, so a new workspace sees the whole product and switches off what it does not run. Each card below states what the module is and — the part that matters when you are deciding — exactly what happens when it is off.
Triage Board
WorkspaceThe board of new escalations awaiting a QA routing decision, with meeting mode and the decision log.
The Triage Board leaves the sidebar, the command palette and the start-page choices. Its address still opens, showing that the module is off. Requires the Triage section to be on.
Analytics
WorkspaceAging, workload, QA closure, risk & trends, patterns and the leadership view.
Analytics leaves the sidebar, the command palette and the start-page choices; Home keeps its numbers, and any Analytics link on it opens the module notice.
Handover Readiness
WorkspaceThe shift-readiness view over escalations — what the next shift needs to know about open records — its drawer on a record and its card on Home and My Actions. Separate from the Shift Handover record.
The Handover Readiness page, its drawer on a record, the Home widget and the My Actions card are hidden. Records keep any handover notes already written.
Triage (on a record)
RecordThe Triage section of an escalation — QA screening, the impact assessment and the routing decision.
The Triage section is hidden on records that have no triage yet. A record that already carries a triage, or whose closure needs a triage decision, still shows it — closure rules do not change. The Triage Board is switched off with it.
Interviews
RecordThe Interview section of an escalation — structured personnel interviews (5M&E) and their completion.
The Interview section is hidden on records with no interview requirement and no interviews. A record whose triage requires interviews still shows it and still waits for them — a switch never waives a recorded requirement.
Handover (on a record)
RecordThe Handover section of an escalation — the QMS / deviation / process comment handoff notes.
The Handover section is hidden on records with no handoff notes; a record that already has them still shows it. QMS references stay reachable from the QMS drawer; handoff notes never gate closure.
Batch Record Review
WorkspaceDigital batch-record review: manufacturing findings become tracked actions for named people, and the QA review starts only once every manufacturing finding is complete.
Batch Record Review leaves the sidebar and the command palette; its address still opens, showing that the module is off. Reviews already recorded are kept, and its settings stay in Administration.
Daily Management
WorkspaceTier meetings on a daily cadence: each team's KPIs against target, the items discussed when one is off, the actions that follow, and the support a team asks of the tier above it.
Daily Management leaves the sidebar and the command palette; its address still opens, showing that the module is off. Teams, KPIs, meetings and actions already recorded are kept, and its settings stay in Administration.
Shift Handover
WorkspaceThe shift handover record: what changed, what needs attention, what is still underway and who owns each action — prepared during the shift, handed over at the end of it, and acknowledged by the shift coming on.
Shift Handover leaves the sidebar and the command palette. Its addresses still open, showing that the module is off. Handovers and items already written are kept, and reappear the moment the module is switched back on.
A module changes the view, never the rules
This is the single most important thing to understand about the module system — and the question an auditor is most likely to ask. A switch is presentation. It is deliberately not a permission, and it is not a control.
What a switch does
- Adds or removes the destination from the sidebar and the command palette.
- Adds or removes the section from a record, and the choice from the start page.
- Shows a plain notice at the module's own address, so a bookmark or an old link explains itself instead of failing.
- Applies to the whole workspace, from one setting an administrator can change back.
What a switch never does
- Grant or remove a permission. Who may triage, decide, close or review is a separate model, enforced in the database, and a module switch does not touch it.
- Change a closure rule. A record that needs a triage decision to close still needs it with the module off.
- Waive a requirement already recorded on a record — a required interview stays required.
- Delete anything. Data written under a module survives the module being switched off.
Hiding is not securing. If a module switch could stop someone acting, then every access question would have two answers to reconcile — the permission model and the module list — and the second one would be the easy one to get wrong. So the switch is deliberately confined to presentation, and access is answered in one place: roles and permissions, enforced by the database rather than by the screen.
Read the security postureWhat buyers ask about modules
Does switching a module off change who can do what?
No. A module switch is a presentation gate: it decides which surfaces appear in the sidebar, the command palette, the start-page choices, the sections of a record and Administration. Permissions, tenant and site scoping, and the database rules behind them are a separate system and are unchanged by a module switch. Turning a module off is never a way to stop somebody doing something.
What happens to records already created under a module that is switched off?
They are kept. A record that already carries triage, interviews or handover notes still shows them, and a record whose closure needs a triage decision still asks for it — closure rules do not change. A switch hides a surface; it never deletes data and never waives a requirement that was already recorded.
Which modules are on when a workspace starts?
All of them. Every module ships switched on, so a workspace sees the whole product on day one and switches off what it does not run. Because a switch only hides a surface, there is no failure mode for an off-by-default to protect against.
Who can switch a module, and does it apply to everyone?
An administrator, in Administration → Modules. The setting belongs to the workspace, not to a browser or a person: it is stored per company and applies to everyone signed in to it.
Do modules depend on each other?
One does. The Triage Board is the shared view of records in triage, so it requires the Triage (on a record) section: switching triage off on the record switches the board off with it, and Administration says which of the two is the reason. The other six stand alone.
Can we get a module built for our process?
Batch Record Review began as one company's paper review sheet and is now a module every workspace can switch on — so the honest answer is that it happens, as design-partner work rather than as a configuration option. Much of what looks like a new module is really configuration of an existing one: the forms, the questions, the categories and the lifecycle are already yours to shape. Tell us what you run and we will say plainly which it is.
Batch Record Review, end to end. How a batch moves from the line to a manufacturing review to a QA review, why QA cannot start early, and how a finding becomes somebody's named job with a due date.
See the batch review flowThe boundary, drawn clearly. What lives in OgmaQ, what stays in your validated QMS, and why the line is a feature — so every compliance conversation starts answered.
See how we draw the lineBring the list of what your site actually runs.
We will switch the demo workspace to match it — and show you the modules you would leave off, so the product you see is the one you would use.
Or email hello@ogmaq.com directly.