Regulatory Publishing Software: Choose the Right Workflow

This guide is for regulatory operations teams deciding where publishing belongs in their toolchain. Start with the output you need and the work your team can own. A new authoring tool may help prepare content while your existing publisher remains essential; a publishing service may be appropriate when your team has approved documents but limited publishing capacity.

The decision here is which workflow to buy and operate. For a vendor shortlist after that decision, use the eCTD publishing software comparison. Keep the same requirements when moving between the two: the right product for a new application may be unsuitable for an existing dossier.

Map the work before comparing software

Use the following responsibility map in a requirements meeting. The roles are suggested assignments, not a mandatory organization chart. Name a real owner and backup for each output; one person can hold several roles if your process permits it.

A dashboard label such as “complete” is useful only when its meaning is defined. An author may mean that drafting is complete; a publisher may mean that compilation finished. Neither status establishes transmission or agency acceptance. Keep the document, package and submission states separate, even if one platform displays them together.

The diagram shows proposed responsibility boundaries, not an Assyro product screen. The acceptance record below adds space for your actual system, receiving owner, object identity, evidence and decision at each boundary.

Download the publishing acceptance record (.xlsx)

Run the CEDAR example later in this article against these rows. Keep a missing approval record visible as unknown and an incorrect reference visible as failed. The receiving owner can accept the handoff only after the required evidence and corrections satisfy your agreed process.

First choose the application and operating scope

Write down the receiving authority and center, submission type, format version, new or existing application, required history, planned route and target date. “FDA support” or “eCTD ready” is too broad to settle this decision. Add whether your work spans several clients, affiliates or publishing providers, because access and ownership must survive those boundaries.

As of September 14, 2026, FDA's eCTD v4.0 implementation page says CDER and CBER accept new applications in v4.0, with acceptance beginning September 16, 2024. It describes forward compatibility for existing v3.2.2 applications as a future phase. Do not infer that buying a v4.0 publisher lets you move an existing v3.2.2 application into v4.0 today.

Choose one of three starting paths:

• Existing application: establish the complete usable history and required continuation workflow before considering a replacement. A directory of exported files alone does not prove that the new system can continue the application.
• New application: establish the eligible format and regional implementation, then qualify the proposed workflow against that scope. Capabilities advertised for a different authority do not fill a gap.
• Content preparation only: define the accepted deliverable for the retained publisher or service. Avoid buying a full publishing replacement when the unresolved work is drafting or document review.

Assyro publishes this guide. Our starting recommendation is to evaluate Assyro for a suitable connected preparation and publishing workflow, with the offered capabilities demonstrated against your requirements. Assyro does not support eCTD v3.2.2: exclude it as the publisher for a scope that requires that format. Confirm the precise authority, document task and downstream handoff before selecting it for another scope.

Authoring software versus regulatory publishing software

Authoring determines what a document says and the evidence supporting it. Publishing organizes the authorized content into the required submission structure and manages its technical presentation and context. Validation evaluates the object supplied to a checker against a stated set of rules. Gateway submission transfers the released object through the selected route. These functions can be connected, but one output does not substitute for another.

The responsibility map above shows the complete path. Use it to distinguish an authoring deliverable from a publishing deliverable in a statement of work. “Generate the submission” is ambiguous: the supplier might mean a draft narrative, a set of final documents, a compiled package, or actual transmission. Replace that phrase with named objects and acceptance evidence.

Source: Assyro demonstration screenshot from our product marketing materials, reviewed September 14, 2026; captured build unspecified. The authoring product page provides workflow context. The visible controls help distinguish preparation, compilation and checking, but this empty document view does not establish that any package was generated, validated or submitted.

For an authoring purchase, specify the source set, document type, review process and receiving format. The receiving publisher might need an editable document plus a final rendition, or it may own rendition creation. Decide who resolves source questions, approves changes, repairs document links and supplies placement metadata. A writer's export button does not decide these responsibilities.

For a publishing purchase, specify the accepted input state, application context, compilation scope, technical checking and release responsibilities. Establish whether the supplier creates renditions or only consumes them; whether it handles the relevant history; and who corrects a finding rooted in the source document. A publisher should not silently rewrite a scientific conclusion to make a document easier to process.

Consider a fictional team with an approved summary in DOCX and three source reports. The authoring tool exports the summary successfully. The service agreement, however, requires final publishing renditions, placement metadata and the approval record. Only the DOCX arrives. The correct result is authoring export completed; publishing handoff incomplete. The document coordinator must supply the missing evidence or revise the agreed handoff with the publisher. Calling the DOCX a validated eCTD package would hide unfinished work.

The reverse misunderstanding also matters. A technical checker may find no blocking issue in the supplied package while the narrative still cites an obsolete source. Preserve scientific review as its own control. Ask what the checker examined, which configured rules it used and what was outside its scope. A report about file or package conformance does not establish that every statement is supported by the correct study.

Choose the purchase that closes the actual gap. Keep a capable publisher when authors need better source handling. Keep a working authoring process when the bottleneck is compilation or application history. Buy both only when their combined deliverables and operating responsibilities justify the change. Record the retained systems in the budget, because their work remains even when a new platform improves an earlier stage.

Evaluate Assyro document management against the source approval and rendition handoff defined in this section.

Integrated platform versus separate tools or a publishing service

An integrated platform can reduce repeated entry and make status visible across stages. Separate tools can preserve an established authoring environment or specialist publishing capability. A service changes who performs the work. These are operating choices: cloud versus local deployment is a different dimension and does not establish which tasks are included.

Compare the approaches with the same workload. In the fictional CEDAR program, the sponsor must prepare one new-application package from five approved documents. The sponsor retains scientific approval and final release authority. One document references another, and the team must retain the final package and submission responses. No product has been tested in this example.

Now introduce a failure: the integrated proposal says “end-to-end,” but the demonstration stops at package download. The vendor expects the sponsor to transmit through its own account. This may still be a useful platform, but the external submission dependency must appear in the scope, schedule and price comparison. If no authorized person owns it, the workflow is incomplete. An impressive authoring-to-compilation demonstration cannot close that gap.

Apply the same scrutiny to separate tools. A publisher may accept a document but reject its reference format, or a service may deliver a package without the approval record the sponsor expected to retain. The extra handoff is acceptable when the parties define the object, acknowledgment, correction owner and response time. It becomes fragile when those details depend on an individual's memory.

Choose the integrated approach when the exact required stages are evidenced, internal transitions preserve the records you need, and the operating model fits your team. Choose separate tools when retained systems already perform critical work well and the interfaces can be verified. Choose a service when you need execution capacity or expertise, provided the sponsor can inspect the deliverables and retain necessary records. A service does not remove the sponsor's own approval and oversight decisions.

Compare the complete cost: licenses, configuration, migration, template preparation, integration, intended-use assessment, training, support, correction work and retained systems. Record who handles an urgent rejected handoff outside normal hours. A lower subscription price is not a lower operating cost if it transfers substantial reconciliation work to your team.

For CEDAR, the decision remains open until the candidate shows the same reference and approval handoff. A credible service with a complete delivery record can be preferable to an integrated offer with an unowned transmission step. Conversely, a demonstrated internal handoff can remove a recurring manual reconciliation task. Select on that evidence, not the number of modules in the brochure.

The sponsor–CRO collaboration scorecard tests access, review ownership and final handback when two organizations share the work.

Authoring-to-publishing handoff acceptance checklist

Use this editorial checklist after agreeing the handoff specification and before accepting content for compilation. It is a proposed team control, not an agency checklist. Define the required output formats, identifiers, metadata and evidence locations for this assignment first; an unspecified requirement cannot receive a pass.

Record pass when the agreed evidence satisfies the criterion, fail when it contradicts it, unknown when the evidence is missing, and not applicable only with a scoped reason. A row can be closed only by its assigned owner under the agreed process. Retain the original finding and the evidence supporting the new result.

Apply the rows to this small, synthetic portion of CEDAR's handoff. The agreed input is summary SUM-2 v4, report REP-7 v2, final PDF renditions, module placement metadata and version-specific approval records. SUM-2 references REP-7. This is a new application with no preceding application history required for this exercise. The package itself has not yet been compiled.

The received inventory lists both versions correctly and both PDF files open: H1 and H2 pass for these two items. The reference map says the summary should open REP-7 v2, but opening the link leads to an unrelated report: H3 fails. A correct filename in the inventory cannot compensate for a wrong reference destination.

The summary has its approval record, but REP-7's record was omitted: H4 is unknown for REP-7, and the overall approval check remains open. Do not call the document unapproved without evidence; do not accept it as approved either. The placement record matches the agreed brief, so H5 passes. H6 is not applicable because this scoped new-application handoff has no required prior history. That reason would be invalid for an assignment requiring continuation of an existing application.

For H7, the coordinator creates issue CEDAR-12, naming SUM-2 v4, the incorrect destination and the publishing owner. The owner acknowledges receipt: H7 passes for this return-path exercise. Acknowledgment does not close H3. The publisher repairs the link, supplies a new identified rendition and records the change. The relevant owner determines whether that modification requires renewed approval under the agreed process. The receiver then rechecks H1–H4 for the affected objects and verifies the corrected destination. The document owner supplies REP-7's missing approval evidence before H4 can pass.

The disposition is hold the affected handoff, not “submission rejected by the authority.” Nothing has been sent. If the provider cannot correct the link or recover approval evidence, escalate through the agreed exception process; do not invent a green result. Preserve the accepted input version so the later package can be traced back to this decision. Other required documents in CEDAR still need their own checks.

When approved sources live in SharePoint, use the version-specific integration checklist to test what the publisher actually receives.

Release, transmit and retain are separate decisions

After accepting the inputs, inspect the compiled output against the declared application scope. Preserve the exact package identifier, tool and rule-set versions, findings, corrections and release decision. If a correction changes the output, identify the new package and rerun the affected checks. A report about an earlier package is not evidence about an unexplained later file set.

Assign gateway operations explicitly. FDA's ESG NextGen FAQ distinguishes submission routes and acknowledgment handling, and describes authorization when an agent submits for a sponsor. Its new-user testing provisions depend on the center and submission type; do not impose a universal test-submission prerequisite from an old implementation checklist.

Have the submitter record the transmitted package identity and the returned identifiers. Have the designated operations owner read the applicable responses and decide the next action. An upload progress bar, transmission receipt and downstream response are different evidence objects; define which state each supports in your process. Where a finding requires correction, preserve the unsuccessful attempt and follow the applicable resubmission procedure rather than overwriting its history.

Keep your own retrievable package archive. FDA's FAQ says users cannot retrieve the uploaded files from ESG NextGen's Unified Submission Portal. The portal's submission details and acknowledgments therefore do not replace your retained package. Establish access for a successor before the original submitter leaves or the publishing contract ends.

Compare eCTD viewer workflows if independent reviewers need to inspect and retain findings outside the publishing application.

Turn the workflow into a purchase and implementation plan

Give each candidate the same scope brief and the CEDAR-style handoff exercise. Ask for the offered edition, required modules, supported configurations and evidence for each mandatory task. A roadmap item cannot satisfy a current deadline. An unresolved requirement stays unresolved until demonstrated; a confirmed gap excludes that candidate from the required scope.

Evaluate product quality controls separately from submission technical checks. Ask your quality and regulatory owners to determine applicable record, signature, access, retention and intended-use requirements. Obtain the supplier evidence needed for that assessment. A supplier's general “compliant” label or standard qualification pack does not establish that your configured process meets all applicable obligations. This guide does not prescribe one universal CSV, CSA or IQ/OQ/PQ pathway for every system.

Plan implementation around evidence-producing milestones: agree scope and owners; configure the intended workflow; prepare controlled inputs; exercise the difficult handoffs; qualify the configured use as appropriate; train the actual operators; and rehearse release and retrieval. Include an unavailable reviewer and a rejected document in the rehearsal. A successful demonstration by the vendor does not show that your own staff can recover from those events.

For a replacement, define where active documents finish and where new work begins. Preserve a rollback or continuity path appropriate to the current workload. Do not require an arbitrary number of parallel production submissions; choose the transition evidence and duration based on the risks and dependencies of your process. The implementation plan explains how unresolved inputs affect the forecast.

Finally, assign acceptance authority. The document owner accepts content, the publisher accepts publishing input, and the designated release owner authorizes the package under your process. The same organization may perform all three, but the decisions still need identifiable evidence. This makes the contract reviewable and gives operators a clear way to stop when a prerequisite is missing.

Bring a defined workflow to the evaluation

Start with one application and list the exact objects that must cross each boundary. Mark the retained systems and owners, then choose an authoring improvement, publishing replacement, integrated workflow or service evaluation. Use the eCTD software RFP template when you need to turn those decisions into supplier requirements.

Discuss your publishing workflow with Assyro with the format, authority, input state and required output already named. Ask for a demonstration of the eligible scope and retain a clear list of work that remains elsewhere. The useful outcome is an operable workflow with supported decisions and recoverable records.