Google Workspace and the shared-document habit

What connects

Google as your identity provider through OIDC, with directory groups driving role assignment and deprovisioning in the Admin console removing access here.

Drive as a controlled-copy destination, where released documents are published as read-only PDFs, watermarked with the revision and superseded automatically when the source revises.

Docs and Sheets under revision control, held here as objects with revisions and relationships, opened for editing through Google's own editors when a working revision is in progress.

The always-editable problem

A Google Doc has version history, which sounds like revision control and is not. Version history records every keystroke session; a revision is a deliberate statement that something is now true and has been approved. The first is a log, the second is a decision.

The distinction shows up the moment somebody asks what a specification said when a batch was built. Version history can answer *what the document contained on that date*, which is a different question — it includes edits in progress, a half-finished paragraph, and a change somebody made and reverted an hour later.

So a Doc under revision control here follows the same lifecycle as any other document. Working revisions are editable in Google's editors. On release, the content is captured as an immutable revision and a watermarked PDF is published to Drive. The Doc keeps living; the revision is what the record points at.

This is the seam teams push back on hardest, and the pushback is usually *but everyone can already see it*. Visibility was never the problem. The problem is that everyone can see something that changes, and nobody can prove what it said.

The failure it prevents

A test procedure lives in a Doc. A qualification run is executed against it and passes. Eight months later a customer audit asks to see the procedure the qualification was run against.

The Doc has been edited nineteen times since. Version history contains all nineteen states and no marker saying which one the run used. The team reconstructs a best guess from timestamps and hands over a screenshot of a version history entry.

The audit finding is not that the procedure was wrong. It is that the organisation cannot demonstrate which procedure was followed — and that finding costs more than any of the nineteen edits ever saved.

How it meets the rest of the product

Documents held here carry relationships a Drive folder cannot express: a procedure attached to a quality record, a specification attached to an item revision, a report attached to the change that required it. That web is what makes an audit answerable in minutes rather than days.

Released revisions are immutable and hash-referenced in the audit trail, so the question *which revision was this run against* has an answer that does not depend on anybody's reconstruction from timestamps.

Access control here is not inherited from Drive. Drive sharing governs the Drive copy; Manufacturing PLM's permission model governs the record, and the two are deliberately independent — a document made link-shareable in a hurry does not silently widen who can read the product data it belongs to.

Search reaches the content of held documents, scoped by permission, so a procedure is findable by what it says rather than by whether somebody remembered a naming convention. That is the capability teams expect from Drive and quietly do not get once a folder passes a few hundred files.

Change control covers documents the same way it covers structures. A specification revision that requires approval moves through the same workflow as a part revision, with the same approvers and the same recorded outcome — which is what stops document control becoming a parallel process with its own rules and its own gaps.

How it meets your ERP

Where your ERP references a document — a drawing on a purchase order, a specification on a supplier record — it references the controlled copy in Drive rather than holding an attachment. A reference supersedes itself; an attachment is a snapshot of the day somebody uploaded it.

Google Workspace deployments skew toward smaller manufacturers, which usually means a cloud ERP such as NetSuite or Acumatica and a system-of-record matrix with fewer contested rows — the ERP holds cost and stock, Manufacturing PLM holds definition, and there is rarely a second document system arguing for either.

The seam itself is unchanged by any of it. Identity provider and document distribution are operational choices; they do not decide which system owns a field.

Where the boundary is

Drive is not the system of record for a controlled document. The published PDF is a distribution artefact. Editing the source Doc after release does not change the released revision, and it is not supposed to.

Manufacturing PLM does not index Drive, does not import folders wholesale, and does not present Drive contents as product data. A document becomes product data when somebody makes it one — deliberately, with a classification and a relationship — not by being in a folder that got connected.