Quick Answer
A SharePoint integration with eCTD software should deliver the authorized source version to the intended publishing task and retain evidence of that handoff. Compare a documented connector, controlled export and manual transfer against the same checks. A successful sync, familiar filename or visible “Approved” status alone does not prove that the correct document was selected for a submission.
This checklist is for teams keeping source documents in a SharePoint document library while preparing submission output in a separate publisher. The scope is document selection, transfer and reconciliation. A SharePoint document version and an eCTD sequence are different records; the handoff must preserve their relationship.
Microsoft's current documentation, including Microsoft Graph v1.0, was checked September 14, 2026. The examples are synthetic procurement exercises, not executed connector tests or a statement that checklist completion guarantees agency acceptance. Assyro publishes this guide.
Choose the handoff you can support operationally
Start with the work volume, source-control process and responsibilities you can maintain. Automation can reduce routine transfer work, but it still needs a demonstrated selection rule. A manual route can be appropriate when its inputs and checks are explicit.
| Route | What the proposal must specify | Practical tradeoff |
|---|---|---|
| Documented connector | Exact supported library, account, source-selection behavior, trigger and receiving operation | Recurring transfers may require less operator effort; someone must maintain configuration and investigate failures |
| Controlled export | Authorized version list, exported artifacts, manifest and receiving reconciliation | Creates an inspectable handoff boundary; export and import remain separate controlled tasks |
| Manual transfer | Named operator, retrieval procedure, destination mapping and independent check | Can serve a limited workload; each transfer retains human effort and selection risk |
Do not compare a connector's license with a manual route's zero license fee while omitting the latter's operating work. Conversely, a connector that transfers the newest file regardless of approval is not automatically preferable to a controlled export that selects the intended source correctly.
For a supplier claiming SharePoint support, identify the specific product and release, deployment, library configuration and integration mechanism. A Microsoft Graph API in the platform does not establish that the proposed eCTD product has implemented a particular connector or workflow.
Check the source-to-publisher boundary
For each item, record the observed evidence and one result: pass, fail, unknown or not applicable. Missing evidence remains unknown. Use N/A only with a stated scope reason; it cannot excuse an unresolved mandatory publishing input.
| Observable check | Evidence to inspect | Owner |
|---|---|---|
| The intended library and item are identified | Site/library identity and persistent item reference in the source register | Document controller |
| The selected version is authorized for this task | Version reference and the actual approval or release decision for the submission | Document owner |
| The transfer retrieves the selected artifact | Received file matches the authorized source and transfer record | Transfer operator |
| The intended account can read the permitted item | Successful read using the proposed operational account | SharePoint administrator |
| The account cannot read excluded material | Denied read for a separate safe test item outside its permitted scope | Security owner |
| The publisher uses the accepted input | Publishing input record points to the reconciled file and version | Publishing owner |
| A later source change is handled explicitly | Change record and decision to retain, update or hold the publishing candidate | Document owner |
| Required metadata remains available | Field comparison or retained mapping for each required value | Document controller |
| A failed transfer remains visible | Failure record, assigned owner and recorded recovery | Integration owner |
| The released output remains retrievable | Independent retrieval of the exact output and associated source record | Records owner |
These are buyer acceptance criteria. The individual library's settings, your document process and the receiving publisher determine how each is met. Confirm the authority, submission format and required publishing operation independently; connecting SharePoint does not expand a publisher's supported formats.
Verify approval evidence separately from version visibility
SharePoint can be configured for content approval, versioning and control over who sees drafts. Microsoft explains that draft visibility depends on the library settings and the user's permissions. A file visible to an editor may therefore differ from what a reader sees. Test with the account the transfer will actually use. How versioning works
Define what authorizes a source for this particular submission. That may involve the configured approval process and a separate release decision identifying the intended version. Do not infer authorization from a major-version number, a folder named “Final,” or a filename ending in “approved.”
There is an important configuration boundary: Microsoft's instructions say that enabling content approval for a list or library that already contains items marks the existing items Approved. That system state does not, by itself, demonstrate a document-specific review decision. When inheriting a library, inspect the approval history and your release evidence before using status as the selection criterion. Require approval of items in a list or library
Keep the selection rule narrow enough to audit. It should identify the item, version, intended use and evidence that makes it eligible. If an approval record is missing or inconsistent, stop that item at the handoff and ask its owner to resolve the gap. Do not repair the record by merely renaming the file.
Ask how the connector retrieves that exact version
Microsoft Graph v1.0 provides an operation for listing a file's versions. That can help establish which versions exist, but a version list is not an approved-source register. The integration must apply the buyer's eligibility rule and retain the result. List versions
Its version-content documentation also has a useful limit: the specific-version download operation does not support getting the current version's content; Microsoft directs current-version retrieval to the separate driveItem content method. Ask the supplier to show both cases it needs to support rather than assuming one example request proves them all. Download version content
For a current source that can change during transfer, demonstrate how the actual retrieved file remains associated with the accepted version. The implementation may use a documented snapshot or reconciliation approach. The buyer outcome is precise source identity, with an exception if that identity cannot be established. Do not claim a particular API call guarantees the whole process without executing and inspecting it.
Then follow the source into publishing. DOCX-to-PDF conversion will normally create a different artifact, so its file digest will differ from the source. Retain the conversion relationship and inspect relevant content, tables and links. A digest can establish identity within a stated artifact boundary; it does not establish scientific equivalence between two different formats.
Worked example: stale, current and unapproved are different
The synthetic PINE program prepares one submission using a report in SharePoint library REG-DOCS. The source register identifies item R-18, version 5.0 as authorized for the current publishing task. Version 4.0 is an older approved report. Version 5.1 is a later working draft without release authorization. These are document-version labels, not eCTD format versions or sequence numbers.
The publisher's staged report is called study-report.pdf in all three cases. That filename cannot identify the source. The required transfer record must connect R-18 5.0, the received source, the conversion and the staged PDF. An independent operator must be able to retrieve that relationship without asking the original publisher to explain it.
Assume the following evidence is supplied for a documentary review. The observations are stipulated exercise inputs, not measured product results.
| Supplied evidence | Checklist result | Required next action |
|---|---|---|
| Packet A records R-18 4.0 and its old approval | Fail: approved historically, but stale for this task | Document owner supplies the authorized 5.0 source; publisher replaces the candidate and repeats affected checks |
| Packet B records R-18 5.1, selected as the newest file | Fail: newer but not authorized | Hold that input; owner resolves source eligibility before preparation continues |
| Packet C records authorized 5.0, matching received source and a reviewed conversion relationship | Pass for these source and conversion checks | Retain the record; assess the other release requirements separately |
| Packet C has no negative-access exercise | Unknown for excluded-content access | Security owner performs the permitted test and records its result |
| Historical item displays Approved only because approval was enabled on an existing library; no release decision is available | Unknown for task authorization | Document owner investigates the missing decision; status alone cannot close it |
| The agreed scope is a one-way source transfer with no return of publisher output to SharePoint | N/A for automated output writeback | Records owner identifies the separate output archive and required retrieval check |
The last row does not make archive retention optional. It says only that automatic return to SharePoint is outside the agreed design. The exact released package and its evidence still need a defined location and responsible owner.
Now introduce a late change: after Packet C is accepted for staging, the owner authorizes a revised source for the same task. Record the change and inspect its effect before releasing the candidate. If the owner instead confirms that 5.0 remains the intended source for this submission, retain that explicit decision. A change notification should produce an accountable assessment, not an unexplained automatic replacement of prepared output.
Preserve the evidence after transfer and after release
The handoff record should identify the source library/item/version, authorization evidence, transfer time and operator or process, received artifact, destination and any exception. Where a conversion occurs, identify the generated artifact and the review that connects it to the source. Keep identifiers usable after the original operator leaves the project.
Test retrieval from the archive that will actually remain available. A SharePoint link may be convenient for daily work, but the records owner must decide what evidence is required if permissions change, a document moves or the integration contract ends. Do not assume that a source-library version history contains the publisher's final package, technical report or delivery record.
Measure the chosen route using real work: time to reconcile a transfer, investigate a failed item and reconstruct a released document's source. Include those tasks in the operating cost. No time saving or error-rate improvement is established by this proposed exercise.
Evaluate Assyro against the same source requirement
Assyro supports SharePoint storage sync. That establishes a storage connection, not every approval-filtering, historical-version, writeback or publishing behavior in this checklist. Bring the actual library configuration and permitted version-selection case to an evaluation of the authoring workflow.
If the publishing task requires eCTD 3.2.2, retain a supported publisher: Assyro does not currently support that format. A SharePoint connection cannot resolve the limitation. A supported preparation handoff can still be assessed separately, with the remaining publishing responsibilities explicit.
Discuss your SharePoint document handoff with Assyro. Ask for the correct-source demonstration, its access boundaries and the work that remains with your team before deciding whether to use a connector, controlled export or manual transfer.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.