Schools & Fleets — Operational Help

1. Workspaces & boat access

Every account has a Personal workspace and may also belong to one or more org / fleet workspaces (schools, hire fleets, clubs). Each workspace is a separate operational space — its boats, members, billing, and inventory are isolated from your personal side and from other workspaces.

The workspace switcher in the top-nav scopes the boat list, the All Boats page, and the org-level menus (Billing Queue, Organization Inventory, Checklist Templates) to the active workspace. Personal owner-operators only see their own workspace and never see fleet-only menu items.

One boat = one operational workspace. A boat lives in exactly one workspace at a time — never simultaneously personal and fleet. See Boat transfers for moving boats between workspaces.

2. Roles & permissions

Five org-membership roles, each with a specific operational remit:

• Manager — full access to the org, all its boats, members, billing, templates, and settings.
• Office staff — administrative access (billing queue, members) without full management privileges.
• Maintenance / mechanic — access to assigned boats; can complete tasks, log service, resolve defects, manage parts.
• Instructor — access to assigned boats; can run checklists, log service, raise defects.
• Owner / client — read-only access to the boats they're attached to; sees history but cannot edit operational records.

Boat-level access for non-manager roles is granted explicitly via BoatAccess — being a member of the org does not automatically grant access to every boat. Managers and office staff see all boats in the workspace; the other three roles only see boats they've been attached to.

3. Shared checklist runs

A checklist on a fleet boat is a shared operational record. Any authorised user with access to the boat can open it and complete items — the next person sees what's already done.

• Auto-save: each item completion saves immediately and links to the underlying PMS task where one exists.
• Multi-user continuation: two instructors, or an instructor and a mechanic, can work the same checklist in turn until every item is resolved.
• Closing / locking: once a checklist run is closed it becomes an immutable operational record. Re-opening means starting a new run from the same template.
• Read-only viewers (owner / client) can see the run but cannot tick items.

4. Instructor workflow

• Open the boat's Checklists page before a session and continue an in-progress run, or start a fresh one from a fleet template.
• Tick items as you verify them — each tick is saved instantly and visible to the next instructor.
• If something fails or is missing, raise a defect instead of leaving the item blank. The maintenance team picks it up from the Defects page.
• Close the checklist when the pre-sail / post-sail inspection is complete. A closed run is the operational record for that sail.

5. Maintenance / mechanic workflow

• Use the All Boats page (scoped to the workspace) to see overdue tasks, in-progress work, and open defects across every fleet boat.
• Open a task to log work, enter parts used, attach photos, and record the outcome (passed / issue found / temporary repair / could not complete). Follow-up tasks are generated automatically where appropriate.
• Resolve defects with a service record — the defect link is preserved so the history shows what the repair was for.
• Mark work in progress or waiting for parts so the dashboard reflects current shop state.

6. Defects & follow-up work

A defect is an operational follow-up signal raised by anyone with boat access — typically an instructor finding something during a pre-sail check. Defects are visible to the maintenance team and drive repair work.

• Severity: Critical (boat unsafe), Important (resolve soon), or Normal.
• Status flows: open → in progress → awaiting parts → resolved / won't fix / deferred.
• Resolving a defect links the resolving service record to the defect so the history thread is preserved.
• Defects do not automatically take the boat offline — that's a fleet-policy call. The dashboard surfaces critical-defect counts so managers can act.

7. Fleet checklist templates

Define a checklist once at the org level and copy it to selected boats. The copy is a snapshot.

• Edit a template at the org level — future copies inherit the change.
• Existing boat copies become independent after the copy: editing the template does not retroactively change copies already on boats. This is deliberate — a fleet operator can tune a checklist for a specific boat without breaking the master template.
• Items in a template can be wired to specific PMS tasks so a tick on the checklist completes the underlying task and updates due dates.

8. Boat transfers — moving boats into fleets

A boat can move between workspaces (e.g. an owner donating a boat to a school's training fleet, or a charter company moving a hull between two fleet workspaces). Transfers are admin-led and explicit; there is no self-serve doorway.

• All service history, equipment, inventory, certificates, and defects move with the boat.
• Existing checklist runs and tasks are preserved.
• Permissions are rebuilt against the destination workspace — boat access in the old workspace is removed.
• Billing for the boat shifts to the destination workspace's billing owner.

9. Operational history & attribution

• Every service record, defect, and closed checklist run records the user who completed it. The Service History page shows the attribution alongside the date.
• Filter the history by user, date range, or category to audit a specific instructor / mechanic's work.
• Internal work records (e.g. mechanic notes not relevant to owners) default to not owner-visible — they appear in the mechanic's view but not on owner-facing exports.
• CSV export is available from each boat for resale, end-of-season reports, and external audits.

10. Multi-user behaviour

• Pages do not lock. Two users editing the same task or checklist will both save; the most recent write wins on conflicting fields.
• Service records, defect-state changes, and checklist completions are append-only and attributed — they are not overwritten by a later edit.
• Older service records cannot overwrite newer ones (future-dated completions are rejected).
• If you see a stale value after a colleague saved, refresh the page — there is no live push.