Documents

The Documents view turns your project’s own data into written deliverables — a project charter, a status report, a risk register write-up, and so on. Each one is drafted from the registers, stakeholders, and project details already in the project, not written from scratch.

The document catalog

Which documents a project offers comes from its methodology — the way of working you picked during onboarding (PMBOK, ISO 19650, or Agile). See Create a project.

The available documents are listed under Documents in the sidebar, grouped by type. For example, a PMBOK project offers a Plans group (project charter, project management plan, communications management plan, stakeholder engagement plan, lessons learned) plus a Reports & summaries group; an ISO 19650 project offers information-management deliverables (EIR, BIM execution plan, MIDP, TIDP, and others); an Agile project offers backlog, release, and sprint documents. Every methodology shares the same Reports & summaries group — the register narratives (status report, risk register, issue log, decision log, action item log, stakeholder register).

Note

A document in the list may show “Generator not yet available”. That means the deliverable belongs to your methodology but the app can’t draft it yet — pick another, or check back later.

Generating a document

Open a document from the sidebar, then use the button at the top right:

• Generate — drafts the first version.
• Regenerate — drafts a fresh version from the current project data.

Generation is an LLM pass (an AI model reads your project data and writes the document). It pulls the relevant registers and project details and composes the text from them, so the result reflects what’s actually recorded. The generators are instructed not to invent detail that isn’t in the data — where a section has no source data, the draft says so or leaves a brief placeholder instead.

A draft can take a little while. When it finishes, the document appears below, showing its version number, when it was generated, and the model used (when recorded).

Who can open a document

Every document is written for an audience, and it only uses what that audience is allowed to see. The audience decides who can open it afterwards.

• Everyone on the project is the default. The document draws only on items every project member can see — nothing from a higher clearance level, nothing from a compartment, and nothing still waiting for its confidentiality review. Anyone on the project can open it.
• A narrower audience. If your clearance is higher than everyone’s, a picker appears beside Generate. It lists every level from yours up to everyone’s. Pick one to include the items people at that level and above can see — Project director and above for a leadership report, say. You can also include one compartment you belong to, such as Bid confidence. Only people at that level or above (and in that compartment) can open the result. An org admin can pick any level and any compartment, or org admins only, which draws on everything in the project.

Each version says who can open it next to its version number (“visible to: …”). The version dropdown only lists versions you can open, and latest means the newest version you can open. A newer version for a narrower audience does not appear for people outside it.

A version also stays tied to the items it was written from. If one of them is later restricted — an admin moves a risk to a higher clearance level, or a ClickUp list turns private — anyone who can no longer see that item can no longer open the version either, nor any plan that lists that version. For them it is as if it didn’t exist, and latest falls back to the newest version they can still open. Regenerate to give them an up-to-date version. Deleting an item doesn’t hide anything.

A plan lists the latest version of each kind of document by name, its own earlier version included, and some plans count them too. A plan is hidden by the versions it lists, but not by the versions those list in turn: it names them, and quotes nothing they list. So when a version is hidden from you, the next plan of that kind is hidden too (it lists that version), but the one after it opens again, if its own items allow, however many plans came before. It also means a plan you can open may name or count an earlier version you can’t open, by its kind, number and title alone.

What your role may read counts too. If an admin sets a role so it can’t read a register — risks, say, under Roles & permissions — people in that role can’t open any version written from a risk, nor any plan that lists one. The same goes for an API token without that register’s read. The default roles can read every register, so this only happens after someone edits a role. The link to a version’s filed PDF only shows to people who can read Files.

For the same reason, you can’t generate a document you couldn’t open yourself. If your role can’t read documents, or can’t read a register that kind of document is written from, Generate stops with a message before anything is read or written — whether or not that register holds anything yet. A plan that lists earlier versions needs every register’s read, since an earlier version can be written from any of them. Ask someone who can read them to generate the document. Finalize & file likewise needs your role to read both documents and Files.

Task owners are named only when the audience can see the owner. A task whose owner is a person the audience can’t see shows the owner as typed on the task, or (unassigned).

Scheduled runs are always written for everyone on the project.

Note

Documents generated before audiences existed are visible to org admins only, because they were written from everything in the project. To make one available again, Regenerate it — the new version is written for the audience you choose.

Versions

Every Generate or Regenerate creates a new version — earlier versions are kept, not overwritten. The view shows the latest version you can open by default; when more than one exists, a version dropdown at the top right lets you open any earlier one (read-only). Each entry shows its version number, when it was generated, who can open it, and — for scheduled runs — that it was produced automatically.

Finalize & file

A generated document lives in this view until you decide it’s the record copy. Finalize & file renders the version you’re looking at to a PDF (built on the server — no printing to PDF from the browser) and files it as an issued document in the project’s Files tree, in the folder the filing standard allocates for that kind of plan (a PMBOK management plan files under 10_Management, for example).

Finalizing a later version written for the same audience adds a new version to the same filed record. Filed copies are treated as outputs: the platform doesn’t re-ingest its own generated documents back into project intelligence.

The filed PDF is never shown to more people than the document is:

• It is filed at the document’s audience, or at the folder’s own restriction when that is narrower (a folder marked internal or admin-only).
• It is never visible to partners. A document for everyone on the project is written from every company’s items, so its PDF is filed at the widest level partners can’t reach (Client project team on the standard ladder). People at the Delivery partner (PM) level can read the document in Documents, but not its PDF in Files. To share the PDF with a partner, an admin re-classes it in Files on purpose.
• It stays tied to the items the document was written from, as the document does. If one of them is later restricted, or your role can’t read their register, you can’t open the PDF in Files either: not in the list, not by link, not in search, not in a download, a share link or a transmittal. A record in Files holds a PDF of every version filed into it, and every one stays downloadable, so a record is hidden from you if any of them is.
• So an admin who re-classes a filed PDF wider in Files reaches only people who could see the items it was written from.
• If the generated document a PDF was filed from no longer exists (a project’s documents were reset), nothing says any more what it was written from: the PDF opens only to people whose role can read every register.

You can finalize a version only when you could open the PDF it would file, and only while every item it was written from is still visible to its audience — otherwise regenerate it first. So if the folder the document files into is classed above your clearance, finalizing is refused before anything is filed: ask someone who can open it — an organisation admin, say — to finalize instead. A version written for one compartment can’t be filed into a folder kept for a different compartment.

A version written for a different audience is filed as its own record rather than as a new version of the first one. The same goes when someone has since re-classed the filed PDF in Files, narrower or wider, or when it holds an earlier version you can’t open: the next finalize files a fresh record at the version’s own clearance and leaves the other one as it is, so a PDF you can’t open is never added to, or described, by your finalize. A document visible to org admins only (one generated before audiences existed) can’t be filed — regenerate it for an audience first. Its Finalize & file button is greyed out and says why.

PDFs filed before audiences existed were written from everything in the project, and they keep the clearance they were filed at. Your platform team can list them, and narrow them to org admins only if that’s wanted.

Scheduling

The Status Report can regenerate itself on a weekly schedule, so a fresh one is always waiting without anyone clicking Generate.

Go to Settings → General → Scheduled status report and:

• Turn on Generate automatically.
• Pick the day and time. These are in the project’s own timezone — set the timezone under Settings → General first; without one, the schedule uses UTC.
• Set the look-back — how many days of activity each report covers (7 by default).

Each scheduled run saves a new version, exactly like a manual one. It does not email anyone or post anywhere — open it from the Documents view, where scheduled runs are tagged as automatic in the version dropdown. A schedule runs at most once a day, and only while the project is active. Changing the schedule needs document write access.

Note

Only the Status Report can be scheduled today. Other documents are still generated on demand.

Permissions

You need read access to a project’s documents to open this view, and write access to generate or regenerate. Document access is governed by your role’s permissions, and each version by its audience — see Who can open a document.