BROWSER WORKFLOW · WORKSPACE UI 17

Complete a checklist

Find the job, record the work, then synchronise and review

Find the intended record

Open Checklists in the main sidebar. Use Search checklists for the reference, checklist type, project, vessel, equipment or record date. Type & sort contains the type filter and saved-update, created-date or reference sort. The active choices remain visible when the panel is closed.

Open work shows records with an unfinished stage. Issues & review is a subset with saved issues, deferred checks, pending item approvals or requested changes in unfinished stages. Ordinary Pending checks alone do not put a record in that subset. Closed means every stage is finalised. All records includes both; postponed, cancelled and archived records are accessed separately through Record management. Status counts are calculated before the search/type filters.

Select View summary or the record reference. Desktop shows its saved stages and details beside the list. Mobile opens the summary full-width; Back to checklist records restores the list. Selecting this summary does not join a stage, record a result or finalise anything.

Use Open [stage name] to enter the existing working checklist. It refreshes the saved record and follows the established participant/heartbeat and local-sync workflow. View-only access still depends on current service permissions. Returning with Back to checklist search or Back to filtered checklists retains the current session's list context. This is temporary navigation state, not a new offline queue.

Create a standalone checklist or use a Task

Confirm the active project. Choose New checklist / dive, select an active published type, and review its title, revision and stages. Enter the job details. Dive/record number is optional: an empty value displays a stable REC- reference, not an invented dive number. Creation requires a connection and appropriate access.

A new record starts with blank answers. Leave Live checklist off unless the record needs deliberate item changes during the job. Existing records retain their reviewed checklist revision; publishing a template does not rewrite them. Administrators can author browser definitions in Administration → Templates & routines. Unsupported definition extensions and native file-import procedures still have their existing limitations.

For assigned work, use Tasks and its existing task-owned checklist workflow. A standalone record is not automatically attached to a Task. The Unsent checklist work on this device notice opens saved-work review; Continue new checklist resumes the existing new-record draft where creation access remains enabled.

Work in the stage without losing your place

The opened stage has three areas: Checks, Team & stage review, and Instructions & source. Read the instructions before carrying out the work. Record tools contains Record details, Export PDF and Help. The stage links retain the saved workflow order and labels.

In Checks, use Search this stage to find wording, check numbers, saved/local notes or reading values. Choose a Section. Desktop has status buttons; a phone uses Show. All checks shows everything in that scope. Needs attention includes unfinished results, local drafts/queued entries and outstanding required approvals. For later shows deferred checks in the selected scope, not a separate unfiltered list from every section. Item approvals shows checked entries pending synchronisation or approval, or with changes requested. Local work includes drafts and queued/conflicting entries. Recorded includes saved Completed/N/A without outstanding local work, but required approval can still be pending.

Clear filters returns to all sections and checks. Find next unfinished clears narrow filters, shows Needs attention across the whole stage and focuses the first matching check in template order. It never marks a result or submits a form. Counts on desktop filter buttons are calculated for the selected section before text search; the matching count also applies the search. Filtering never exempts a hidden check from finalisation.

The saved-result summary uses the last server snapshot, excluding local drafts and queued changes. Individual cards can display a queued result while the saved totals remain unchanged. Show local work and Review saved work make that distinction explicit. Choices remain in memory for the same record/stage/session; changing session or stage resets these filters. Open editors block the new navigation controls; they must be finished or closed before changing the working view.

Review the whole stage separately

Team & stage review brings together required item approvals, participating devices and the existing readiness/finalisation actions. Its links show outstanding checks, approvals or local work across the whole stage. Opening this area does not send a readiness or finalisation request. A zero attention count is not a substitute for the service's final checks.

Done on this device opens the UI17 saved-stage/device review; confirming locks editing on this device until it is resumed online. It does not complete checks. Finalise stage has a separate UI17 saved-checks, participating-devices and confirmation guide for authorised finalisers. Pending, Issue and For later results, invalid or missing required approvals, evidence integrity, local work and participant readiness keep their existing service checks. Details are described below. Finalised stages stay locked. Neither action authorises equipment use.

Record one check with the guided form

In a standalone record's Checks area, open a check or resume its saved local draft. The UI16 form follows Result & readings → Notes & photos → Review check. It records one checklist item in the selected stage. Task-owned checklists retain their separate workflow. Standalone approval, device readiness and finalisation have the separate UI17 guides described below.

On Result & readings, review the check wording and reference guidance before carrying out the work. Record identity & last known result shows the record ID, checklist revision, stage and saved item metadata. This is the snapshot already held on this device, not a fresh online verification. A teammate can have saved newer work. The status starts from the action you selected, an existing result or the retained draft; it is not an automatic completion.

Enter the actual readings. Fields marked required must be present for Completed. Recorded numeric limits still apply. Issue needs a description; Not applicable needs a reason. For later remains unfinished and does not schedule a reminder. Reference pictures and guidance remain available; they are not submitted evidence.

On Notes & photos, enter the reason or work notes. When photographic evidence is enabled, use the existing Take photo or Choose photos controls and review the images and captions. Required evidence needs at least one photo for Completed or N/A. The existing five-photo limit, JPEG/PNG handling, compression and local photo budget remain unchanged. Photos stay local until the check is saved and synchronised. Removing an earlier submitted photo from this proposal does not delete its audit history.

Review check compares the Last known hub result with the Proposed result on this device, including readings, notes, photo counts, draft base revision and last known hub revision. Inspect the actual images on the previous page; counts and captions do not verify photo content. A retained draft is not silently rebased onto newer saved work. The existing conflict workflow may be needed for an older draft.

Confirm the reviewed proposal explicitly, then choose Save check on this device. The confirmation is not stored in the draft. Back, changed fields, photo edits or resuming a draft require a fresh review. A changed known hub snapshot also blocks an already reviewed proposal until reviewed again. Pressing Enter before the final page advances the guide; it does not queue a completed result. Saving uses the existing check queue and operation/revision protections; watch the save-status strip for hub confirmation.

Keep draft & close explicitly retains the form locally. The close button or Escape also leaves edited local work in the established draft store; neither queues a result. Discard draft requires confirmation and removes only that local draft, not the saved hub result or an already queued check. Photo preparation and the current save block ordinary closing. Storage failures are shown: do not assume the draft was durably retained after an error, and do not clear site data.

The changed editor checks its initiating account, project/session, route, record, stage and dialog before scoped actions. A delayed photo operation cannot open its enlargement over a replacement form or attach its new photos after that context changes. This is a focused form guard, not an acceptance claim for every module, durable browser storage or device. Existing server permission, finalised-stage, participant-readiness, conflict and approval checks remain authoritative.

Saving a check is not approval, device readiness or stage finalisation. A required reviewer still uses the separate approval action. No operational authorisation is granted by the software. Opening the guide, moving between pages, reviewing or keeping a draft never sends a new check result to the hub.

Record checks without confusing the action and result

1. Instructions & source: Open Checklist document details and Read before starting and read the applicable instructions. Tap reference pictures to enlarge them. These panels preserve their open/closed state during a same-view refresh.
2. Open each applicable item. Record its result, required readings and notes. Use N/A only where appropriate, with a reason. Required photographic evidence needs at least one submitted photo for Complete or N/A; reference pictures do not count.
3. Save and synchronise with the hub. A local draft or queued completion is not an acknowledged server result. Resolve conflicts and pending entries before relying on the shared copy.
4. For Awaiting approval, the designated reviewer uses Review approval. Checking does not approve automatically. When the existing rules allow the checker to review their own work, it is not an independent review; follow your organisation's separate-review procedure.
5. Before finalising, resolve outstanding work and approvals, synchronise participating devices and complete team readiness. Done on this device is not Finalise stage. Finalise a two-stage checklist in order.

The catalogue displays server-saved completed and N/A counts separately; its progress bar is their combined count, not a finalisation decision. For later stays unfinished. Unsent item drafts and queued changes are shown separately and are not added to the saved stage counts.

Review a hub-saved item decision

Use Review approval for the exact standalone check. UI17 follows Saved result & evidence → Decision & note → Confirm review. It reads the current named account and retrieves the saved record before opening the working review. Unlike the UI16 result editor's last-known snapshot, this review has a fresh saved read. Expand Saved review identity & timing for record ID, checklist revision, saved stage revision, hub snapshot time and device retrieval time. The display is not continuously live.

Review the saved result, actual readings, technician note, checker and assigned reviewer. Submitted photographs use new authorised requests rather than the earlier shared image cache. Each image must decode before it is counted as available. Enlarge photograph opens separately without replacing the review. A missing or unreadable submitted photograph is unavailable, not evidence that no photo was submitted. Decisions remain blocked until all submitted photos can be viewed. Required missing evidence still blocks approval. Received times are hub timestamps, not verified capture times; reference pictures remain instructions.

Choose Approve checked item or Request changes explicitly; approval is not preselected. Request changes requires a note. Only the designated person or enabled assigned-group member may decide: administrator access is not an override. The checker may review their own result only when assigned, with both actions recorded under that account. This is not independent second-person review.

Review the saved item revision, selected decision and note, then confirm and use Save review decision. Back, changed text, refresh or a changed known snapshot requires a new confirmation. Approval does not complete other checks or finalise the stage; a saved decision resets team readiness for the stage. Later answer/evidence changes invalidate the approval under the existing service rules.

Review notes are not locally saved drafts and are not queued offline. Refresh saved review keeps the note text only inside this open review, clears the decision/confirmation, and retrieves the saved state again. Closing warns before discarding an unsent nonempty note. A failed refresh clears old evidence and disables actions; its retained note is available to preserve in the open review. No note is submitted merely by viewing, changing pages or refreshing.

Mark only this device ready

Open Team & stage review → Done on this device. The guide follows Saved stage & this device → Confirm readiness. It shows saved counts, the signed-in person, exact device ID, stage-local work count, hub-reported unsent work and saved stage revision. Its preparation refreshes the account, sends the existing stage heartbeat and retrieves the saved stage. A heartbeat can register or update this participating device; it is not a readiness or finalisation decision.

Preserve local drafts and synchronise queued/conflicting work before readiness. Confirm Mark this device ready only when finished on this device. This locks its editing until Resume editing is used online. Other devices are unchanged. Unfinished saved checks do not by themselves prevent readiness: ready is a device declaration, not a claim that the checklist is complete. It does not approve an item or finalise a stage. An already-ready device is shown as such; use the separate resume control to edit again.

Finalise the saved stage

An authorised finaliser uses Finalise stage, following Saved checks & N/A → Participating devices → Confirm finalisation. Preparation uses the current account, existing heartbeat and a fresh saved stage read. The first page shows server-saved counts, outstanding checks, N/A reasons and required item approvals. Expand check rows for the saved author, readings and notes. Recorded approval labels are not an independent recalculation of evidence integrity; the service's saved approval counts and final validation remain authoritative. Missing count information is unavailable, not zero.

Participating devices lists every returned participant for this stage, including name, exact device ID, reported unsent work, snapshot connection state, readiness revision and last-seen time. It is not a full crew roster or a count of every offline browser. An offline device is not ready just because an older ready flag exists. These values can change after reading; the hub checks them again when finalisation is submitted.

The final review states known blockers. Pending, Issue or For later checks, outstanding required approvals, an unfinished earlier stage, missing current-device participation and devices not online/synchronised/ready prevent a final action. Local work is checked again before submission. No listed blocker is a preliminary snapshot result, not guaranteed acceptance: the service also verifies current evidence and permissions. Confirm explicitly and choose Finalise stage. Success saves the existing finalisation receipt and locks that stage, not the other stage or merely the dialog. It does not authorise a launch.

Changed records, stages, routes, accounts, tokens, devices or replacement dialogs guard the changed review paths before and after asynchronous work. The optional send guard rechecks scope after lease renewal. Ordinary Close/Escape and duplicate submissions are blocked while a reviewed action is in progress. An already-sent request may still finish; these controls cannot cancel a committed hub action. Late outcomes must not close a replacement form.

A refusal clears confirmation and requires Refresh saved review. A lost response does not prove the action failed to save: check the save-status strip and read the saved outcome before another action. There is no automatic offline retry. If the hub confirms but local snapshot persistence fails, the review explicitly says not to resubmit. Preserve other unsent work. These are scoped browser safeguards, not durable-storage, security, whole-product or physical-device acceptance.

Interrupted connections and stale summaries

Answers in an already loaded record retain their existing local-save/reconnection behaviour. Creating records, approving and changing checklist structure need a reachable hub. Hosted access does not add automatic vessel/cloud synchronisation or permanent offline storage for every module.

A failed list refresh displays a Saved list — refresh failed notice and clears the selected summary; existing saved local work is retained. Reconnect and refresh before treating the summary as current. An authorisation failure hides the previous list/detail rather than displaying it as current access. A response for an old account or superseded list request does not overwrite the current account's list.

Do not clear browser site data, uninstall the phone app or change the address with unsent work. Reconnect and synchronise, or export the available local recovery copy and ask the project administrator for help. Server backups cannot include work still held only in a browser.

Reports and retained originals

Use Record tools → Export PDF from the opened working record. Review its reference, stages and finalisation status; an active-record report is not proof of completed or approved work. Follow Record photographic evidence for uploads and Set up item approval for reviewer assignments.

Linked originals open under Instructions & source → Checklist document details → Linked original documents. Retrieval needs a hub connection and a compatible viewer. The linked revision stays exact; adding a newer original does not replace a saved record's source. Closing a record never authorises equipment operation.