What's new in the Shift Log module — every change that makes your day easier, in plain language, not developer-speak.
With the “Reporter” add-in, each site can have a public page where residents report odour, noise, smoke, flaring or dust — without signing in or cookies, with bot protection. The report arrives as an event tagged “Public”, and the reporter can follow its status on a secret link. The organisation admin switches the tier on, tailors the privacy notice, and the page can also be embedded in the organisation’s own website.
For plants that produce in campaigns: a campaign moves from the approved production plan to closure through phases (Planned → Start-up → optional Ramp-up → Production → Shutdown → Closed), with signed gates before each phase change, recorded in a hash chain. The start-up checklist comes from the plant’s base list or a template, and the shift completes it. A phase indicator sits in the diary header and the shift PDF, and progress is calculated from the quantities in closed diaries. A system administrator can request it on the Add-ins tab of the Control panel.
Besides the usual status, a task can be a tick (yes / no), an inspection (OK / not OK / N/A) or a measurement (number + unit), and each task sets whether a photo or a note is required. It can be assigned to a specific person or to a group (“anyone of these people”); recording on someone else’s behalf needs a reason and is tracked. The “Assigned to me” filter shows yours.
A sign-in lasts 8 hours by default, but your organisation’s administrator can set it between 4 and 13 hours — so it covers a 12-hour shift plus handover without signing out mid-shift. Nothing changes for existing organisations until they change it.
The shift log is now a switchable module: an organisation can run on Permit to Work and Analytics alone. The shared master data — site, plant, shift type, functional location — is always there, whichever modules are on.
Photos are downsized on the device before upload — less mobile data, faster uploads, and an oversized original is no longer rejected. The size follows what the server keeps anyway, so quality does not drop.
Signed-in users can also record a company-level event from Reports → Events; it waits for classification and can be reassigned later. In Analytics a new “Events” view shows the trend and the breakdown by type, severity, source and status at company, site and plant level.
Every event gets a unique identifier (E-year-site-number) and can move through statuses from new to closed, with a closing reason. In the Reports → Events table it is filterable; the side panel has a timeline, comments and edits that leave a trace. The log and its PDF show the identifier only.
The PM calendar shows what is due in the next 30/90 days in week, month and list views. The compliance report measures how much was done on time, late or missed (CSV/XLSX export). The Analytics dashboard shows failures and recovery time per asset. The functional-location tree can be loaded from xlsx/CSV, with a preview.
Labour is recorded on the work order by rate category, and costs as line items. Amounts are visible only with a separate right, and lines cannot be overwritten — a correction is a reasoned reversal line. One currency per organisation (HUF or EUR); CSV/Excel export.
A contractor, visitor or someone from another plant can report a fault by scanning the QR label, without an account — the report becomes an event in the shift log, not a separate system. The feature is switched per organisation (off by default); the description can also be dictated, if dictation is on.
The first tab of Control panel → Settings shows, across 19 steps, what is done, missing or blocked — one click to the exact setting. It names, for example, what a scheduled report still lacks to be sent, so it does not silently fail to go out.
When the connection drops, saving the log and uploading a photo are queued and retried when it returns; a bar at the bottom shows the state. Two people editing at the same time no longer overwrite each other silently. This is not a full offline mode.
We walked the shift log through 106 scenarios and Analytics through 198, and fixed the defects found. Among other things: a log correction now issues a new PDF version.
A closed log shows the permits issued in that shift, in their end-of-shift state, and the maintenance planned for the shift’s day; the log PDF can include this block too. Every occurrence of a task is visible in the archive as well.
If an invitation cannot be delivered (the email bounced), the list flags it with a badge. An expired link also shows on the list, with a clear error message. An invitation link is valid for at most 7 days.
The organisation’s language applies even before sign-in; the invitation email and factory role names arrive in English, and the Permit to Work factory texts display in English — on existing permits too.
From the photo viewer the filtered photos can be downloaded as a ZIP (up to 500 photos and 500 MB), with a manifest. A log “Image” field can take 1–10 photos, and the log and its PDF show them all.
Master data → Functional locations has its own tab, editable even without the maintenance module. Your organisation can choose: an event’s location from the list only, or from the list or free text. Reports can be filtered by location too.
Photos can be attached to the log (up to 10). A photo shows as a thumbnail and opens in a large view. Deleting needs a reason, and the trace — who, when, why — remains. The upload screen reminds you that no person should be recognisable in the picture.
Text fields can be filled by dictation using the browser’s built-in speech recognition — OPEREX does not record or store the audio. The organisation’s administrator switches the feature on (off by default).
The translation add-in can now work with two machine translators: Anthropic Claude (with a choice of models) or DeepL. Which one translates is set per organisation. The company glossary applies to both, and names, numbers and equipment tags still stay untouched.
Five pages for auditors and procurement: how the system shows that a signed permit or a recorded action was changed afterwards — the chained fingerprint, the daily external anchor and the QR code on paper. It also states the limits: what we do NOT claim.
Over the past weeks we kept strengthening the supplier side. Two-factor sign-in is available to every user, and your organisation can make it mandatory; the person affected gets an email when their two-factor is turned off or reset. Our internal security policies became controlled documents, with versions and change history, their content re-checked against the running system.
Until now a sign-in expired roughly every hour during a shift — the "Keep me signed in" box did not change that. From now on a sign-in lasts a full shift, 8 hours, so the box has been removed from the sign-in page. At the end of the shift the session expires; on a shared computer, still sign out when you are done.
When you change or reset your password, every OTHER browser and device is signed out immediately — the session is revoked on the server, not left to expire on its own. A forgotten or compromised sign-in ends on its next click. On top of that, a per-tenant fingerprint of the audit trail is taken every day, chained and stored off-server: a later change to an already anchored day — even one made with owner rights inside the database — can be detected.
If your organisation falls under NIS2 (in Hungary, Act LXIX of 2024), you have to assess your suppliers too — and until now that work meant extracting the facts from us one question at a time. We now hand it over ready-made: a public page and a downloadable supplier data sheet that map the ten Article 21(2) measure groups onto what the system actually does. In an incident we notify you within 24 hours — that figure exists so your own 24/72-hour reporting deadlines stay achievable. Important: this is not a certification and it does not make you compliant; NIS2 applies to your organisation, what we do is make the supplier side verifiable. Our limits are stated on the same page.
A supplier is easy to choose when it is easy to leave. Your full data set can now be handed over: EVERY data table in machine-readable (NDJSON) and spreadsheet-openable (CSV) form, with an inventory of stored files and a SHA-256 checksum per file, so you can verify the package is intact. The package also names whatever is deliberately left out of it, and why. If you then ask for deletion, we issue a certificate: what was deleted, the result of the post-deletion check, and the fingerprint of the export we handed over first. Data leaves the backups with the rotation, within 90 days at the latest — we say that plainly, because backups are taken of the whole database.
Before issuing, the issuer can prescribe preparation steps. They land among the shift’s tasks with a "Permit" label, and if your organisation configures it, the permit cannot be issued until the required ones are done.
A backup is worth what has been restored from it — so we did it. From the off-site backup (every 6 hours, to EU storage) we restored the entire database into a separate instance and counted: every table, every row and every user account came back intact. We checked the canonical shift-log PDFs separately: every one of them has its backed-up file, byte-for-byte identical to the original. The data itself restores in seconds. The full recovery time — which includes rebuilding a machine — is still being measured, and we will only state it once we can back it with a number.
Every archived shift-log and analytics PDF has always carried a fingerprint (hash) that reveals whether the document was altered afterwards. From now on the record also states HOW that fingerprint is to be verified — because they are not all produced the same way. This matters in an audit: the wrong procedure would report a "mismatch" on a perfectly intact document, with nothing to reveal that the fault is in the method, not the document. We classified the existing archive retroactively too — by measurement, not assumption.
The shift-log module went through a comprehensive, multi-dimensional security and reliability review. No critical issue surfaced; the items found were fixed and hardened per good practice.
Shifts record in the local language, but the reader does not always speak it. With the translation add-in, an assigned colleague reads the log in their own language (one toggle, with the original reopenable block by block), and the PDF report sent at shift close arrives in the recipient’s language — attached ALONGSIDE the authoritative original, with the email in that language too. Every page marks the translation as “machine translation — not authoritative”; the original is always the source of truth. Numbers, units, equipment tags and names stay untouched; an approvable glossary can be taught for the company’s own terminology. The admin sets the target language and who receives it translated.
Some plant data has a lifetime that belongs to the process, not the shift: lab results, in-process sampling and batch tracking keep accumulating. The next shift writes into the same series — and sees the history: newest row on top, with its own sampling timestamp and the name of whoever recorded it. Out-of-limit values stand out immediately, and the series downloads to Excel and CSV. You define the columns yourself: label, unit, instrument tag, limits, calculated fields — in the same editor you already use for shift-log elements.
After login you land on an overview home page: the current shift, the diary entry point, the site switcher and your own company content — internal welcome, operational notices, document and intranet links, contacts. Block order, content and page width are configurable in the Console, per site too.
A new, public Help site for the shift log: a concrete task, numbered steps, and what to do when you get stuck. Searchable, in Hungarian and English. Help describes the product — the professional background still lives in the Knowledge Base.
You now assemble the body of the diary PDF from blocks: what appears, in what order, in what table. Settings cascade from company to site to plant — you only deviate where the log really differs.
You can define formulas over the diary fields — closing minus opening stock, hourly average, row totals — and the result appears in the PDF and the export just like a hand-entered value.
Administrators can see when a colleague signed in. In an audit this is the question that had no answer before: “who was logged in when the diary was written?”
The PDF preview now opens inside the app: scrollable and zoomable on a phone. Previously some phones showed only an empty frame.
One organisation can run several sites, each with its own plants, shift pattern and diary. Roles carry site access: everyone sees what concerns them.
A departing colleague’s account can be deactivated in one click: they can no longer sign in, but their logs, reported events and audit trail are kept — nothing is deleted.
The Users tab now lists the invitations you sent with their status — Pending, Registered or Revoked — and a pending invitation can be resent or revoked.
Priority, assignee and target date on each job; per-shift comments build into a chain, and clicking a row opens an editor with every field and the full history.
Carried-over tasks and maintenance jobs now carry a “history” button: a timeline showing, shift by shift, what state the item was in and what was noted about it.
Record the maintenance work done or under way during the shift right on the log — and anything not closed carries over to the next shift by itself, until it is finished.
Rename, colour, reorder and switch the log’s event types on or off; with several plants you can set which type is available at which plant.
Task status is one click along a progress track, the list brings high priority to the top, and the log shows who acknowledged a standing order, and when.
A log can only be closed by hand near the end of the shift, so it can’t be finalized mid-shift by accident; and any changes made after closing — who changed what and when — are tracked on a separate history timeline.
The live log now auto-saves in the background, so the keyboard no longer drops mid-typing on iPhone and iPad — you can keep writing without interruption.
Every closed shift now produces a tamper-proof PDF report — saved to the server automatically and available to download or preview any time.
Archived logs are read-only until you explicitly edit them; closing a log simply finalizes it.
Record exactly who worked each shift, picked from a managed roster of workers (name and position).
Log incidents, near-misses, quality deviations and maintenance-triggering events right on the log — with severity and an open→investigating→closed lifecycle.
A drag-and-drop builder lets you design your log's sections and fields — text, numbers, lists, tables, images — or start from ready-made templates.
One organization can run several plants — switch between them, with per-plant permissions and per-plant log setup.
Turn any datapoint into a CSV/Excel report with a point-and-click builder; saved definitions re-run with one click.
The system opens and closes shift logs automatically from your schedule and timezone — no manual start.
Authorized roles can correct a log, but every change is recorded — nothing can be rewritten silently.
Custom logo, brand color, shift types and timezone per organization; interface language in Hungarian or English.
No entries in this view.
New modules, industrial shift-log tips and ISO 45001 practices — once a month at most, no spam.