Lifecycle & sharing

The lifecycle, in plain English

A controlled (CDE) document moves through four states. The state is the answer to “who is allowed to rely on this?”:

State	Plain English	Who sees it
WIP	A private working copy.	Only the team that created it — your team for your uploads, the partner’s team for theirs. Nobody else, ever.
Shared	Issued for a purpose — coordination, information, review (suitability S1–S4).	Your team, plus any delivery partner whose folder access covers it.
Published	Authorised for use — for construction / approved / as recorded (A, B, CR).	Your team, plus the parties you distributed it to.
Archived	A closed record. Read-only.	Narrower than before. Your team, plus any partner you distributed it to directly. A partner who could only see it through folder access loses it.

The drawer’s Lifecycle section always shows the one action that applies:

• Issue (WIP → Shared): pick a suitability S1–S4. To re-issue at a different suitability, upload the next revision — records don’t mutate.
• Publish (Shared → Published): pick A, B or CR and choose the distribution — which partner organisations receive it.
• Archive (Shared/Published → Archived): closes the record. Note this narrows who can see it — partners who reached it only through folder access lose it, while anyone you distributed or transmitted it to directly keeps it.
• De-issue (Shared → WIP): the one step backwards. See below.

Descriptive documents (non-coded files) are simpler — and in most folders they have no ceremony at all: an upload lands live immediately (file-and-done), visible to everyone the folder is shared with. Two exceptions keep the draft → issued gate:

• Folders the template marks [workflow] — for formal management documents (contracts, charters) where “issued” should be a deliberate act. There, Mark issued is the whole lifecycle, and a new version re-opens the draft.
• Partner uploads, everywhere — a delivery partner’s file always starts as a draft in their portal; their issue is the formal hand-over.

Why can’t I share a WIP document?

WIP is private by definition — the platform refuses to grant, transmit or share-link a WIP document. Issue it first; that’s the act that says “others may now rely on this”.

Taking something back off issue

Sometimes a document goes out that shouldn’t have — the wrong revision, the wrong file entirely. De-issue puts it back: Shared returns to WIP at S0, and an issued descriptive document returns to draft.

Open the document’s drawer, go to Lifecycle, and click De-issue. You must give a reason, because the reason is emailed to everyone who was told the file had landed, along with a note asking them to discard any copy they downloaded. The moment the state flips, the document disappears from every partner’s delivery space — partner visibility keys on exactly these states, so reverting is what pulls it back.

The De-issue button only appears when it would actually work. It is refused, with an explanation, when:

Situation	Why, and what to do instead
The document has been shared with a partner or pinned to a transmittal	The issue reached someone under a reference, and that is a record. Void the transmittal or archive the document.
The document is Published or Archived	Past Shared the record is contractual. Archive it instead.
It was never issued	There is nothing to take back.

The issue stays on the record

De-issuing does not erase the fact that the document went out. The original issue keeps its place in the audit trail and the exchange register, and the de-issue is recorded alongside it with your reason. The history is that the document went out and came back — not that it never went. If you need the file and its traces gone entirely, that is erasure, which is a different, irreversible thing.

De-issue also pulls the document’s content back out of the knowledge base, so answers and search stop citing a document that is no longer issued. Re-issuing it puts everything back.

Sharing with delivery partners

Partners see documents through their delivery space (see Delivery partners). Two mechanisms feed it:

• Folder access — grant folders on the Partners page, or straight from the file browser: a folder’s ⋯ → Share folder… adds the ticked partners (their existing access is untouched). A folder grant covers its whole subtree. The partner then sees every Shared, Published and issued document in those folders (and their own uploads, whatever the state).

  The share dialog shows the folder’s contents as a tree of ticks, all ticked to start. Untick anything the partners should not get — another partner’s WIP folder, say — and only what stays ticked is shared: the fully-ticked subfolders stay live (files added there later keep appearing), while individually ticked files inside a partially ticked folder are shared as they are now and appear in the partner’s Shared with me list. A partially ticked folder gets no grant of its own, so a new subfolder created under it later is not exposed to anyone until you share it. In their portal the partner still sees where the shared folders live — the parent folders above them appear greyed, as context only — so two packages’ identically named folders stay tellable apart.

• Per-document share — the drawer’s Share… panel grants one document; tick several rows in the browser and the selection bar’s Share with partners… grants them all at once. Publish distribution does the same thing as part of publishing.

Recipients are always project participants — organisations with a live delivery space on this project. The pickers only offer those, so a document can’t be “shared” to an organisation that has no way to see it. Partners get an email when something is issued or shared to them.

Share links for people outside the project

For someone with no account at all — a lawyer, a client’s board member, a one-off reviewer — send a share link from the drawer’s Sharing section. Pick a protection level:

Level	What the recipient does	Use it for
Anyone with the link	Clicks the link, sees the document.	Low-sensitivity material, wide circulation.
Named email	Enters their email; it must match the addressee.	The normal case — like a courier addressed to a person.
Email + one-time code	As above, plus a 6-digit code emailed to them on open.	Sensitive material — proves control of the inbox.

Facts that hold for every level:

• The link opens a branded viewer (your name, not ddx) — PDFs and images preview in the page; anything else downloads.
• It shows one pinned revision — uploading P02 later never silently changes what the recipient sees.
• Links expire (1–90 days, default 7) and can be revoked at any time.
• Every open is recorded — view count and last-viewed on the share, a row in the document’s activity, and a distributed line on the exchange register.
• On a named share, someone arriving with the wrong email isn’t silently refused — they can request access, which emails you and is recorded.
• Named shares email the recipient for you; an anyone with the link share just gives you the URL to pass on. Either way the URL is shown once — it can’t be retrieved later, only revoked and re-created.

Which should I use?

Prefer named email. Use anyone with the link only when the material could safely be public. Use email + code when you’d previously have password-protected the file.

Folder links

A share link can also point at a folder — hover the folder in the tree, ⋯ → Share, and use the Link for outside the workspace section. Same three protection levels, same expiry and revocation, but the page is different in one deliberate way:

• The recipient sees a live listing of the folder and everything under it, grouped by subfolder — only what has been issued (shared, published, or an issued descriptive document). Work-in-progress, files pending deletion, and anything inside a retired subfolder never appear.
• Live means live: a document issued tomorrow shows up on the same link; one that’s retired or superseded stops being offered. A document link pins one revision; a folder link always offers the current one — it’s a window onto the folder, not a snapshot.
• Each file is downloaded individually, and every download is recorded against that document — the document’s activity and the project Activity feed show who (the named email, or “link holder” on an open link) took which revision, when. The share itself counts views. Folder links don’t write exchange-register rows — the register records partner exchanges; link-holders aren’t project participants.
• Retiring the folder kills the link (visitors see “no longer available”).

Use a folder link when the deliverable is a set — “here’s everything issued under 05_Handover” — and a document link when it’s one file, pinned.