Processes

Overview

A process is an operating procedure your organization has written down and expects people to carry out. Two kinds share one model:

• A checklist is worked through and submitted. A pre-shift vehicle check, a monthly server-room walkthrough, a quarterly fire-door inspection.
• A report form is filled in and filed when something happens. A damage report, a defect notice, a near-miss.

Each time somebody carries a process out, that execution is stored as a submission. The process is the template; the submission is the record. An auditor asking "show me that you check the ambulance every month" wants the submissions, and that is what this feature produces.

Processes are a different thing from the neighbouring features, and the difference is what to carry out:

Core Functionality

Defining a process

Adding a process asks only for its metadata. The rows or fields are built afterwards, on the process's Structure tab, because a real checklist is dozens of rows and does not belong in a create dialog.

Kind cannot be changed after creation. Existing submissions are shaped by it, and switching would orphan every one of them.

Leaving "Who can run it" empty means everyone. An organization that never thinks about audiences gets the obvious behaviour: every member of the portal can run every process. Naming roles narrows it to the members of those roles.

Building the structure

The Structure tab is split: the editor on the left, a live preview on the right showing exactly what your people will be handed in the portal. The preview follows what you type, so you never have to save and go looking.

Templates offers a set of starting points built on ISO 9001:2015: internal audit (9.2), management review (9.3), nonconformity and corrective action (10.2), customer complaint (9.1.2), supplier evaluation (8.4), job release (8.5.1), measuring equipment (7.1.5) and change request (8.5.6). Picking one replaces the structure you have, and asks you to confirm before it does. Nothing is saved until you press Save, so a template you dislike costs a page reload.

The editor itself has two views over the same document, and both write the same thing:

• The Builder is the visual editor: sections, rows, drag-free reordering, duplicate and delete.
• The Text view is for bulk entry. A ward checklist is sixty rows, and typing them one button-click at a time is why checklists end up staying on paper.

The text format is one section per # line, then one row per line:

# Cab and documents
Vehicle registration document | 1
Warning triangle | 1 | Present and undamaged

# Lights and signals
Headlights | | Both working?

For a checklist each row is Label | Target | Remark. For a report form each line is Label | type | required | Option A; Option B, where type is one of text, textarea, number, date, datetime, select, multiselect, checkbox or priority.

Editing the structure never changes a submission that already exists. Every submission freezes its own copy of the structure the moment it starts, so a checklist somebody submitted in March still shows exactly the rows they were asked about in March. That is also why a submission started before an edit finishes against the old rows rather than jumping to the new ones.

Running a process

Your people run processes in the employee portal, not in the admin app.

A checklist is started, worked through, and submitted. Progress saves automatically, so a tablet on a loading bay that loses its connection does not lose the last twenty ticks. A checklist left open appears to everybody in the audience as "continue what a colleague began" — the late shift finishes what the early shift started, and each row records who ticked it and when.

A report form is filed in one go. The person who filed it can see it afterwards, and nobody else in the portal can: a damage report names people and places, and the reporter is the only employee with a reason to read it back.

Handling a filed report

Filed reports land in Processes → Submissions, which opens filtered to what still needs somebody. Opening one gives you the answers exactly as filed, plus a handling panel:

A resolved report is locked. Editing one again takes an explicit unlock, because reopening a closed record should be a decision rather than a side effect of clicking into it.

The list behaves like every other register: tick rows to select them, then archive, delete or export the selection. Export writes a CSV of the whole list or just what you selected; Import reads one back. An imported row carries the metadata only, because a CSV cannot express a checklist's rows, so each import lands with an empty structure for you to fill in from the Structure tab or a template.

Cadence and deadlines

A checklist with a cadence appears in Deadlines under Recurring Processes, and its next due date is shown on the list and detail pages.

The clock re-anchors from when the work was actually done, not from when it was supposed to happen. A monthly check completed three days late resets to a month from the day it was completed. Otherwise one late submission compresses every following cycle and the deadline list nags forever.

Report forms take no cadence. They are filed when something happens, so a deadline for one would be asking for something nobody can supply.

Notifications

Everything routes through your normal notification settings, under Updates to your items and Deadlines. People who filed a report are usually portal-only employees with no in-app inbox, so for them the email is the whole of what comes back.

Evidence

Processes touch evidence from both ends, and the two mean different things:

• The process's Evidence tab attaches proof to the procedure: the signed-off template, the sign-off email, the training behind it.
• A submission's Evidence tab cites that one execution as the proof. A signed checklist from March is what an auditor asks for; the blank template is not a substitute.

Either way the evidence item then reaches your controls through the normal control-coverage link, so nothing about processes bypasses the coverage model.

Tasks

The Tasks tab lists the work items attached to this process and lets you add one with the process already filled in: rewrite a step that keeps tripping people up, chase the shift that has not filed this month, retire the paper form the checklist replaced. A task belongs to at most one record, so a task filed here is unambiguously about this process rather than about one submission of it.

The Tasks entry in the list's row menu opens the same tab straight from the register, next to Evidence.

Reports

Reports → Process Submissions exports one completed checklist or filed report as a PDF: every row with who checked it and when, how a report was handled, and the full timeline. It renders from the submission's frozen structure, so the export is the record rather than a re-render of today's template.

Archiving

Archiving a process takes it out of every audience, every list and every deadline, while keeping its submissions intact. Deleting one deletes its submissions with it, which is why the list offers archive first.