Drydock

Every piece of work performed during a docking event is recorded as a drydock task. Seven task types cover every source: Maintenance (deferred PMS items), Deficiency (open deficiency records), Non-Conformity (non-conformity records), Technical Finding (technical findings from audits), Predefined (reusable specification items from the predefined task library), Enquiry (deferred enquiry items), and Other (manually specified ad-hoc work). Each type carries its own status lifecycle: Not Started, Started, Completed, and optionally Deleted for administrative removal.

Tasks created from cross-module postponements automatically link back to the originating record — the drydock task carries the source module's document ID and type, creating a bidirectional traceability chain. Manually adding a task requires only a title and category; the system assigns a unique identifier, sets the initial status to Not Started, and emits a task creation event. Bulk task insertion from predefined templates uses batch write operations for guaranteed consistency — all-or-nothing insertion of an entire specification set.

Every drydock task carries two independent rich-text fields with full formatting support: Details (the pre-work scope specification describing what needs to be done) and Report (the post-work completion narrative describing what was actually done). Both fields are stored as separate cloud storage objects with a field-level discriminator in the cloud storage key — neither field can overwrite the other. Content-based deduplication prevents redundant cloud writes when predefined task content is copied across multiple tasks.

At the drydock project level, a third independent rich-text field — the Final Report — provides a single narrative document summarizing the entire docking event. The three-tier documentation structure (task details, task reports, project final report) gives superintendents a clean separation between planning documentation, execution records, and the summary narrative that accompanies the project closure.

When items in other modules are deferred to a drydock period, they automatically surface as tasks in the drydock record. Postponed PMS maintenance logs with DryDock postponement type, deferred Deficiency records, deferred Non-Conformity records, deferred Technical Finding records, and deferred Enquiry records all create corresponding drydock task entries with the appropriate task type and a bidirectional reference to the originating record.

Date change operations on a drydock's scheduled or estimated date trigger a cascade that propagates the new date to every linked postponed item across all five source modules. The cascade is executed server-side as a coordinated update across all linked records within the same request, ensuring consistency across all originating modules without client-side coordination. This means the drydock work scope assembles itself from operational data — no manual re-entry of deferred items, and no risk of date drift between the drydock plan and the originating module records.

The calendar integration engine manages a three-operation lifecycle: CREATE (on drydock scheduling — inserts a calendar event with metadata), REBUILD (on date edit — deletes existing event and creates a fresh record with updated dates), and DELETE (on drydock deletion — removes both the calendar event and its metadata). Every drydock appears on the fleet-wide shared calendar alongside other module events such as audits and surveys.

The calendar event carries the drydock's drydock-type identifier, enabling filtered calendar views that show only docking events. Calendar integration is fully automatic — no manual calendar entry is needed, and date changes propagate instantly. This ensures that fleet planners always have an accurate picture of when vessels will be out of service for docking, without cross-referencing separate scheduling spreadsheets.

The task detail view mirrors the drydock detail view's three-panel structure adapted for individual work items. The west sidebar contains two sections: Information (category, scheduled dates, task status, type badge showing which source module the task originated from) and Expenditures (estimated cost, actual cost with currency codes, subcontractor name and reference), plus the Assignments panel showing ship-side and office-side assignees separately. Start Task and Complete Task action buttons are prominently placed, with the task status lifecycle enforcing the Not Started → Started → Completed transition sequence.

The center panel provides three tabs: Description (the Details editor for pre-work scope specification), Report (the completion Report editor for post-work narrative), and Invoices (the PO-linked expenditure records for this task). The east dock panel provides the same Comments, Attachments, and Events tabs as the parent drydock view, but scoped to the task level and drawing from the 25-event task-level event type set. This separation between the task's east dock and the parent drydock's east dock ensures that task-specific comments and attachments are organized independently from the project-wide collaborative record.

Navatom Drydock provides five dedicated dashboard widgets that give fleet managers and technical superintendents real-time visibility into docking project status without navigating into individual drydock records. The first widget — My Active Drydocks — renders as both a count (active drydocks assigned to the current user) and a detailed table (the underlying list with status, vessel, and shipyard). The second and third widgets — My Open Tasks and My Open Issues — show the user's open task backlog and issue-type tasks respectively.

The fourth widget — My Maintenance Tasks — surfaces maintenance-type tasks specifically, giving technical superintendents a dedicated view of PMS-deferred work awaiting action in active dockings. The fifth widget — Completed Without Invoice — identifies completed tasks that have not yet been linked to an expenditure record, serving as a post-docking financial reconciliation tool. All five widgets are configurable for dashboard placement alongside other module KPI widgets.