SharePoint to eCTD: Approved-Version Handoff Checklist

A SharePoint-to-eCTD integration should deliver the specifically authorized source version to the intended publishing task and preserve evidence of that relationship. A successful sync proves neither source authorization nor submission acceptance. Evaluate a connector, controlled export or manual transfer against the same acceptance checks.

Use this checklist when documents remain in SharePoint and a separate publishing workflow prepares submission output. It covers the handoff, not a repository migration. Microsoft Graph references are for v1.0; FDA examples concern CDER/CBER eCTD submissions. Primary documentation was checked October 6, 2026. The examples are documentary exercises, not executed connector tests. Assyro publishes this guide.

Record the task, then complete the handoff checklist

Start a handoff record with the source site/library, item reference, selected version, authorization record, target application, intended submission task, receiving system and responsible owners. State the eCTD format separately from the SharePoint document version. A document called version 4.0 does not establish that its submission uses eCTD 4.0.

For every row below, add an evidence location, reviewer, review date, result and exception owner. Pass means the stated condition is demonstrated. Fail means evidence contradicts it. Unknown means evidence is absent or ambiguous. Not applicable needs a recorded scope reason. A critical failed or unknown item blocks acceptance of the affected input; it cannot disappear into an average readiness score.

These are proposed operational acceptance criteria, not a claim that each row is a separately mandated regulatory requirement. Add task-specific checks through your procedures. For broader release responsibilities, use the eCTD submission checklist.

Establish source authority before selecting the file

SharePoint's approval, versioning and draft-visibility settings affect what users can see. An editor's view is not necessarily the transfer account's view. Inspect the configured library and exercise the actual account rather than inferring behavior from an administrator's screen. Microsoft: how versioning works.

Microsoft also documents a consequential inherited-library condition: requiring content approval for a library that already contains items marks those items Approved. That setting does not independently establish a document-specific review decision. Preserve this distinction when a library is being brought under a more formal process. Microsoft: require approval of items.

The source register should therefore identify what authorizes this version for this submission. A major-version label, folder named Final or visible Approved status cannot substitute for missing authority. If the evidence is absent, mark authorization Unknown and hold the item while its owner investigates. Do not repair the gap by renaming the document or changing its status without the underlying review.

The same document may be acceptable for internal review and ineligible for submission preparation. Record purpose explicitly so that a useful draft collaboration workflow is not accidentally treated as a release workflow.

Retrieve the authorized version and preserve its metadata

Microsoft Graph v1.0 can list file versions. Its documentation says results arrive newest first and that history retention depends on configuration. Selecting the first result therefore does not implement an approved-source rule, and an old version's continuing availability should not be assumed. Microsoft Graph: list versions.

There is also a specific retrieval boundary: Graph's version-content operation does not retrieve the current version's content; Microsoft directs that case to the separate driveItem content method. Require the supplier to demonstrate both cases if the design needs both. The API documentation establishes available operations, not that a particular publishing connector implements them correctly. Microsoft Graph: download version content.

When the approved source is current and still editable, the design must associate the bytes actually retrieved with the accepted version. A documented snapshot or reconciliation mechanism may achieve that outcome. If a concurrent edit makes the association uncertain, stop acceptance and reconcile; do not relabel an unidentified download as the earlier authorized version.

Map metadata by meaning. For example, a SharePoint column called Study may contain a display label, while the publishing task needs an agreed study identifier. Document the transformation and its owner. Capture the metadata associated with the authorized decision instead of silently pairing historical file bytes with today's column values. Missing historical approval evidence stays missing even when the file itself downloads successfully.

For DOCX-to-PDF preparation, preserve both artifact identities and the conversion relationship. Check relevant text, tables, pagination and links in the output. Matching digests can verify unchanged bytes within a transfer boundary; different formats require a content review, not an expectation that their digests match.

Keep document versions separate from submission lifecycle

The destination record needs an application identity, submission task, placement and intended lifecycle action approved by the publishing owner. Copying a newer SharePoint document must not automatically mean replacing a previously submitted document.

FDA currently lists eCTD 3.2.2 and 4.0 as supported versions, with support for new eCTD 4.0 NDA, BLA, ANDA, IND and master-file applications beginning September 16, 2024. That does not establish the eligibility of every existing dossier or a supplier's capabilities. Confirm the actual application history and route before selecting output. FDA eCTD overview.

For a 3.2.2 workflow, the publisher manages submission tracking and document lifecycle, including the appropriate operation on prior submitted content. FDA's September 2024 Technical Conformance Guide, version 1.9, addresses these in section 2.5. A SharePoint version increment does not determine that operation. FDA eCTD 3.2.2 technical guide.

For 4.0, preserve the information the publisher needs for document identity, Context of Use and keywords. FDA's June 2026 guide, version 1.5, explains that replacement occurs within the same context group; changing placement or keywords is not an ordinary replacement in a different group. The handoff must expose the intended placement change for assessment instead of automatically translating a renamed folder into a lifecycle operation. FDA eCTD 4.0 technical guide, sections 1.5.2–1.5.4.

A proposed 3.2.2-to-4.0 transition needs its own confirmation of current agency availability, publisher support and application history. A SharePoint connection supplies none of those facts. An unsupported required format is a failed route check; an unverified capability is Unknown. Both require resolution before releasing that publishing input.

Distinguish receipt, preparation, release and agency response

Define a receiving receipt as a record that the destination obtained and reconciled the identified input. It should carry the handoff ID, selected source reference, receiving artifact ID, receipt time and disposition. It is not an authorization to submit.

Next, the publishing owner records the prepared output and its checks. The release owner approves the exact package under the team's procedure. After transmission, retain the applicable delivery and agency-response records separately. FDA describes ESG NextGen ACK1 as upload information, ACK2 where applicable as transmission to the Center, and ACK3/ACK4 where applicable as the Center's response. Read the content and applicability of each acknowledgement; its existence alone is not a universal acceptance result. FDA submission acknowledgements.

This separation prevents an interface dashboard's green Transferred status from being reported as Filed or Accepted. It also tells the next operator where work stopped if the transfer succeeded but publishing or agency processing did not.

Exercise the checklist with a later draft and a duplicate

In this invented example, PINE's source register authorizes REG-DOCS item R-18, version 5.0 for publishing task T-27. Version 4.0 is older; 5.1 is a later unauthorized working draft. Handoff H-204 identifies 5.0, authorization A-77 and the intended destination. These are illustrative record labels, not API identifiers.

The receiving workflow records receipt P-880 for H-204 and the reconciled source. A conversion record links that input to the staged PDF. All versions could have the same filename, so filename matching contributes no proof of eligibility.

The duplicate rule is a proposed integration requirement, not a claimed default SharePoint behavior. A retry repeats an existing handoff. A deliberate new use of the same document for another task needs its own task identity and authorization; a global file-hash deduplication rule must not suppress it.

If 5.1 later becomes authorized after 5.0 was staged, record a new decision: retain 5.0 for T-27, revise the candidate, or hold it. An automatic update must not silently replace prepared output. If a package has already been transmitted, escalate through the applicable submission process rather than overwriting the local package and implying the agency received the change.

Use a version-specific handoff diagram and acceptance record

The diagram follows the same fictional PINE source, R-18 version 5.0, through receipt, conversion, staging and retention. The document version identifies the selected source; it does not identify the eCTD submission format.

Download the SharePoint transfer acceptance workbook. Its example packets distinguish stale 4.0, unapproved 5.1 and authorized 5.0. All actual-result cells begin Unknown. Fill in observed results, evidence and the decision owner before treating a row as accepted; the illustrative result in the left columns is an answer key, not your test result.

A Pass for source selection does not close the separate negative-access row. Similarly, N/A for automatic writeback requires a scope reason and owner; required output retention still needs its designated archive. Review the complete checklist above because the workbook's six example rows are not an exhaustive release record.

Choose an operating route and keep its evidence retrievable

A documented connector suits repeated work when its selection, retry and exception behavior can be demonstrated. A controlled export makes the manifest and receiving reconciliation explicit. A manual route can support a limited workload when a named operator follows the same checks and another reviewer can reconstruct the result. Include reconciliation, failure investigation and ongoing ownership when comparing their operating costs.

Retain the handoff record, source authorization, received artifact, mapping, conversion review, released package and relevant acknowledgements in defined locations. Test retrieval without relying on the original operator. A source hyperlink or SharePoint version history does not automatically preserve the publisher's output and delivery evidence after access, permissions or suppliers change.

Use the regulatory publishing software guide to define preparation responsibilities and the regulatory submissions software guide for the wider release workflow. Assess Assyro's document-management offering against the authoritative-source boundary and the receiving system's evidence requirements.

Assyro supports SharePoint storage sync. That does not establish native approval-filtered eCTD publishing, historical-version selection, duplicate protection or output writeback for your configuration. Evaluate the Assyro authoring workflow against the same fixture. Assyro currently supports FDA eCTD v4.0, while v3.2.2 is not supported. For a required v3.2.2 route, retain a publisher that supports that format; a successful SharePoint transfer does not change this eligibility decision.

Discuss the source handoff with Assyro using one permitted library item, its authorization record and the intended publishing route. The useful outcome is a demonstrated boundary with named remaining responsibilities.