How document control works
A document control workspace answers one question, repeatedly: which revision of this drawing are we building from, who said so, and what came back.
Everything below follows from that question being harder than it sounds. The yard has an opinion, the owner has another, class has a third, and the review that settles it takes weeks — so the workspace records all of it against the revision it was said about, rather than collapsing it into one flag.
The register
The register is Documents — one row per document, not per revision. A row carries the document’s identity — its number, the originator’s own number for it, its Damen SYS, its type, who originated it — and then the part that changes: Has current revision, with its date, its file and the yard’s status.
The tabs split the register on Active: In use is what the page opens on; Not in use holds the documents that have been taken out of use. Nothing is deleted in document control, because the drawings that were issued are still on board — so the tab the page opens on is never the whole register.
A document has revisions; a revision has a state
A document is a container. The revisions underneath it are the things with dates, files and statuses, and at most one of them is current.
Which one is a field on the revision, Status: Concept while it is being
drawn, Actual when it is the one to build from, Superseded when a later
revision has taken over. So “make rev. C current” is an edit to one value, and
the register’s Has current revision columns follow it without the document
row being touched. The document page’s two revision tabs are the same filter
seen twice: Actual revisions is status = Actual, Other revisions is
everything else.
The old revision does not disappear. It stays, with its file and the comments raised against it, because somebody on board is holding a printout of it.
Three statuses on one revision
Besides Status, a revision carries two more, and it is worth being precise about them because all three are called “status” somewhere:
| Field | Whose opinion | Values |
|---|---|---|
| Status | the register’s — where this revision sits in its document’s history | Concept, Actual, Superseded |
| Status (builder) | the yard’s — what the engineering department thinks of the drawing | In Progress, For inspection, Under review, Approval from Class, Approval from Client, Approved for Construction, On hold, Voided, Closed, … |
| Status (owner) | the owner’s — what came back from the client | Under review, Clarification, Accept, Accept with comments, Approved for Construction, Cancelled, … |
These are not three names for one thing. A revision can be Actual, Approval from Class and Under review at once: it is the one to build from, the yard has sent it to the surveyor, and the owner has not answered yet. All three are true, and none is a data-quality problem. Reason for change is the fourth field worth knowing: the only one that says what moved between two revisions of the same drawing.
Transmittals: how a revision leaves the building
A revision does not reach class or the owner by being approved. It goes out on
a transmittal — a covering document that says what is being sent, to whom
and why. Communication → Transmittals lists
them: one row each, with the reason (For information, For review and
signing off, For Construction and Approval…), the recipients (a +1
badge when the cell cannot show them all), who owns it internally, the
cover PDF whose date is the date sent, and the signed copy when it came
back.
The column the overview labels Status is the reviewer’s verdict — To do, Approved, Approved with comments, Rejected, Superseded — because that is what a document controller scans the list for. The transmittal’s own state (Concept, Ready for review, Finished) is on the document’s Transmittals tab beside each revision.
Making one
A transmittal is created where they are listed. Right-click anywhere in Communication → Transmittals and the row menu opens with Create Transmittal at the top.
Four things make a transmittal worth sending, and the order is the order of the work rather than a rule the application enforces:
| Where | |
|---|---|
| Number and ID | typed on the new row (TR-010, T-2417-010) |
| Name and Reason | the row as well — the reason is a list, and it is what the recipient reads first |
| Has recipients | the transmittal’s own page: right-click, Select, pick an organisation or a person |
| Includes documents | the same page — right-click, Select, and pick the revisions being sent |
That last row is the one worth reading twice. A transmittal carries revisions, not documents: you are sending rev. C, not “the fire control plan”, because next month rev. D will exist and the transmittal still has to say which drawing went out today.
Sending it: the export
Share, at the bottom of that same menu, is how a transmittal leaves the building.
It is in two places, and they do the same thing:
- on the Transmittals overview, in the right-click menu of the row — the export runs against the transmittal whose row you clicked;
- on the transmittal’s own page, as a button at the top — the export runs against the transmittal you have open.
The second is the one most often used, and for a reason worth naming: the detail page is where you can see what the transmittal actually carries — its recipients, the revisions on Includes documents, the reason — so it is where you are standing when you decide it is ready to go. Sending from the overview means sending a row you are trusting from four columns.
Neither is offered in the client portal. Exporting writes (see below), and the client’s view is read-only.
What it builds is one zip:
| In the package | What it is |
|---|---|
| the cover sheet, as a PDF | generated on the spot — who sent it, to whom, why, the deadline, and the table of what is enclosed |
Documents/ | each selected revision’s own native file, the one its File cell names |
PDF/ | the PDF rendition of each revision, where it has one |
Two folders rather than one, because a revision here carries two files and the
recipient has to be able to tell them apart. The cover sheet says which format
governs if the two ever disagree, and it could not say so honestly if only one
of them travelled. A revision with no rendition simply contributes nothing to
PDF/ — that is a drawing without a PDF, not a file that went missing.
The three ways it can go
Pressing Share opens the dialog, and the choice in it is how the package reaches the recipient, not what is in it. The package is identical either way.
Download saves the zip and leaves the rest to you — you attach it to your own e-mail, or put it on the transfer service the contract names. This is how most transmittals actually go out.
Share link is for a recipient who has no Shipbuilder account. The engine stores the package behind a random URL and returns a password and an expiry — seven days by default. The link and the password are two separate secrets on purpose, and the dialog says so: send the link by one route and the password by another, because a single forwarded e-mail carrying both is the same as no password at all.
Active share links underneath is the part worth coming back to: it lists every live link for this transmittal, who made it, when it expires and how many times it has been downloaded. A count still at zero the day before a deadline is the answer to “did they ever collect it”.
Email would create the link and send it for you. It is greyed out here, and for two reasons that are both deliberate. The training instance has no mail server configured; and this workspace type records no e-mail address on a Person or an Organisation at all — so there would be nothing to send it to. A transmittal’s recipients here are names, not mailboxes.
Company info: what the cover sheet says you are
The cover sheet has a header, and the header comes from exactly one record. Management → Company info is a settings screen wearing a grid: there is at most one row in it, ever.
The overview shows four columns; the rest are on the row’s own page, reached by clicking the name:
| Field | On the cover sheet |
|---|---|
| Name | the top line of the header |
| Address, Postal code, City, Country | the address block under it |
| Phone, Email, Website | the contact line |
| Logo | the image in the header — a file uploaded onto this row, like any other file cell |
If the row is empty, the export still works and the cover simply has no company header. Nothing warns you: the transmittal generates, downloads, and looks subtly wrong to whoever opens it at the other end. It is worth checking once, before the first transmittal of a project goes out, and then never thinking about again.
Comments come back, and they are data
A reviewer’s remarks are not an e-mail. They are comments: records with a text, a status and an author, hung on the thing they are about — the revision, the transmittal they came back on, a space, or a piece of equipment. Communication → Comments lists every one, with tabs per status, and with the revision, document or transmittal beside it.
A comment’s status is the decision about it: Open until somebody answers; then Approved, Approved with comments or Rejected. It is editable wherever the comment is shown, and settling comments is part of the job: the Dashboard shows your open ones, and the document page’s Comments tab splits its revisions’ comments into open and closed.
Created by on a comment is who raised it — the surveyor, the owner’s superintendent, the yard’s engineer — and Created on is when. Together with the revision it hangs on, that is the answer to what was said, by whom, about which drawing, months later.
E-mails belong here too: the correspondence around a transmittal is filed on the transmittal, with a sender and a recipient, and opens in a preview.
Spaces and equipment: what a drawing is about
The ship is in the workspace as well: decks, deck areas, spaces and zones under Configuration, and the equipment placed in the spaces. A revision can be visible in a space — the drawing shows that compartment — and the connection reads from both ends: the document’s page lists the spaces it shows, the space’s Documents tab lists the drawings it appears in, and its inspection reports separately.
So an inspection report is a document like any other — a type, a Damen SYS, a revision with the PDF — plus one link to the space it inspected. And a comment raised on the space, or on the plant in it, sits beside it.
Damen SYS: which part of the ship
Every document has a Damen SYS — the part of the work it belongs to, arranged as a tree under Definition → Damen SYS. The document page shows it in the attributes block; the Damen SYS’s own Documents tab shows every document filed under it. It is the second way into the register, after the register itself: what do we have for the main engine is a Damen SYS, not a search.
The client’s own view
The workspace has two portals. Main is the yard’s: everything above. Client is what the owner opens: a Dashboard, the register and the transmittals — the same records, read-only, except that the owner may add comments and settle them on the transmittals they received. Which portal a person can open is assigned per user, and a workspace with no portal you can open does not appear in your selector at all.
Why this shape
Every part of the above exists because a drawing outlives the conversation about it. A revision is kept after it is superseded, a comment is kept against the revision it was raised on rather than against the document, the yard’s opinion of a drawing is recorded separately from the owner’s and from class’s — because each was said by a different person at a different time, and a workspace that averaged them into one field would be unable to answer the only question that matters when something goes wrong on board:
who approved this, and which revision were they looking at.