Project Document Transmittals: Has the New Drawing Been Stored Internally or Issued to the Other Organisation?

Uploading a revised drawing into your team's document register does not necessarily give another organisation the same revision. If you commission a project document workflow, specify the separate act of issuing an identified set of documents to an identified external audience. A transmittal record should explain what was issued, to whom and for what purpose.

This decision matters when a small design practice, contractor or project team exchanges changing drawings and specifications. It is not the same as approving an engineering change, collecting signatures or choosing an expiring download link. Those may connect to the process, but they answer different questions.

Separate your register from the recipient's register

Oracle Aconex's public Managing Documents learning path provides an instructive model. It describes each organisation having its own private document register. Registering a document makes it available within that organisation, subject to confidentiality controls. Other project organisations do not see it until it is shared with them through a transmittal.

For your requirements, draw the two sides explicitly: the documents your team holds and the documents it has issued externally. Do not let a screen labelled “latest drawing” conceal whose latest copy it means.

In a fictional project, the design team might have uploaded revision C while a supplier still holds revision B. The useful task is to review and issue the intended revision to that supplier, not to assume that an internal update notified everyone. The letters are illustrative, not a prescribed numbering convention.

Make the issue set explicit before sending

Request a review screen identifying the destination organisation, intended contacts, document numbers, revisions and issue purpose. Link the outgoing record to the exact versions selected. A changing “latest file” reference should not silently change the explanation of a historical issue.

These are proposed requirements, not claims that every document-management product implements identical snapshots. Aconex's learning material describes retaining previous versions and using document classification to support finding and reporting on documents. Ask the developer to demonstrate how your actual outgoing package remains explainable after another revision is uploaded.

If a file and its entered revision disagree, give the discrepancy an owner before issue. A filename alone is not a reliable approval process. Agree who may prepare the package and who is authorised to issue it.

Check the organisation-wide audience

Sending to one contact does not always mean only that person can see the document. The Aconex learning path explains that a default transmittal shares the document into the recipient organisation's register, making it visible to that organisation's users. It also describes confidential transmission for restricting sensitive documents to specific people.

Treat this as a reason to inspect the actual distribution model, not a universal rule for all portals. Before commissioning, decide which packages may be organisation-wide and which need a narrower audience. Review the destination and confidentiality setting together. Do not assume an email address determines the complete permission boundary.

Use fictional drawings for demonstrations. Customer documents, commercial terms and real project participants are not needed to explain this feature.

Keep issue evidence separate from acceptance

Agree what your system can honestly show: prepared, issued through the selected mechanism, recipient-register update confirmed, acknowledgement received or technical response recorded. Use only states for which the integration has evidence. These are suggested business distinctions, not standardised Aconex labels.

A document being available is not proof that the intended person read it, understood it or approved construction. The cited Aconex material specifically limits its document event log to the organisation's own perspective; it does not show what other organisations have done with a document.

If contractual acknowledgement or a technical review is required, define that workflow separately with the responsible professionals. Do not infer it from your local download history or from successful message submission.

Demonstrate a later revision and a mistaken issue

For acceptance, upload two clearly different fictional revisions. Issue one to an external test organisation, upload the replacement internally and show that the outgoing history still identifies what was issued earlier. Then issue the replacement through the intended process.

Include a deliberately incorrect destination caught before issue and a restricted package whose visibility is checked using authorised test accounts. Agree the correction procedure for a mistaken issue without promising remote retrieval of already downloaded files. Staff must be able to find the affected audience and record the follow-up.

Bring an empty issue-register example to a project document workflow discussion. First check whether an established document system already handles the requirement. The aim is a clear boundary between internal storage and external issue, not another attachment button.

Primary source and limits

Oracle Aconex Support Central: Managing Documents, especially the document-management and event-log transcripts. These support organisation-specific registers, default and confidential transmittal visibility, retained versions and the event-log scope. Exact issue-set binding, correction rules, approval roles and acceptance demonstrations above are proposed requirements. No live Aconex project was accessed or tested, and no contractual or engineering approval is certified here.