Two platforms dominate the research manuscript submission experience across publishers and societies: Editorial Manager (EM) and ScholarOne Manuscripts (S1M). Both can support rigorous workflows, but each has predictable submission portal quirks researchers should plan for. This guide offers a practical comparison of common technical glitches, a reliable approach to ordering files for PDF auto-generation, and a repeatable method to verify the final HTML proof before approving manuscript submission.

What these systems do (and why the quirks matter)

Both EM and S1M are journal submission management systems designed to collect research manuscript files, author details, declarations, and metadata in a structured way. They also feed those inputs into downstream processes peer review, production, and archiving. That structure is helpful, but it also means small inconsistencies (file naming, figure labeling, reference formatting, permissions) can trigger errors that feel opaque to authors.

Many journals configure EM and S1M differently. Even within the same platform, two journals may impose different file types, different “item type” labels, or different rules for what the PDF builder will accept. That variability is why researchers often look for a website submission service or software submission service when deadlines are tight or when a journal’s portal has unusually strict requirements.

Editorial Manager vs. ScholarOne: the most common differences researchers notice

File taxonomy: EM is “item type–driven,” S1M is often “step-driven”

In Editorial Manager, successful submission often depends on assigning the correct item type to each uploaded file (e.g., manuscript, figure, supplementary material). Many journals also allow batch actions like changing item type for multiple files, which is useful when the system unpacks a ZIP and everything defaults to an incorrect label.

In ScholarOne, the workflow often feels more “wizard-like” (enter information → upload files → build PDF → review → submit). The portal may still ask for file designations, but authors often experience friction later during PDF building or when required fields trigger validation errors near the end.

Practical implication: EM issues frequently come from incorrect item types or file packaging; S1M issues more often show up as late-stage validation or PDF build failures.

Packaging files: EM commonly supports zipped source uploads (journal-dependent)

Some EM journal configurations allow authors to upload a .zip or .tar.gz of source files that gets automatically unpacked, after which item types must be assigned.

Practical implication: If a journal allows packaging, EM can be faster for LaTeX-heavy workflows, but only if file typing is done carefully after unpacking.

LaTeX handling and “do not upload PDF” rules can differ

Some EM journals provide explicit LaTeX instructions, including rules like uploading LaTeX sources under a LaTeX item type and not including a compiled PDF at that stage.

Practical implication: When submitting LaTeX, treat the journal’s portal instructions as higher priority than personal habit. A “helpful” extra PDF can cause conflicts in automated rendering pipelines.

Common technical glitches (and what usually fixes them)

1) PDF auto-generation fails or stalls

What it looks like: The build spins indefinitely, finishes but produces a blank PDF, or generates a PDF missing figures or tables.

What typically causes it:

• An unsupported figure format (or a corrupt image file)
• A large file size that times out during conversion
• Fonts or equations embedded in ways the converter cannot interpret (common in Word-to-PDF pipelines)
• Mixed upload logic (e.g., uploading both a fully composed PDF and source files when the journal expects only one approach)

What usually works:

• Re-export figures to a journal-safe format (always follow the journal’s guide)
• Reduce file size without changing resolution requirements
• If the portal accepts it, upload a single clean manuscript PDF for initial submission and provide sources later (journal-dependent)
• Rebuild the manuscript PDF from a “clean” source file (accept tracked changes, embed fonts, re-render equations)

2) “Required field missing” appears late in the process

What it looks like: Everything seems complete, but the final submission page flags a missing checkbox, contributor role, funding line, or ethics statement.

What typically causes it:

• The system treats some fields as conditional (e.g., clinical trial registration appears only after selecting a study type)
• A co-author’s email or affiliation formatting fails validation (extra spaces, special characters)
• ORCID prompts not fully completed (journal-dependent)

What usually works:

• Review each metadata tab again after file upload, because some portals re-check requirements after attachments are added
• Copy-paste content into a plain-text editor first to remove hidden characters, then paste into the portal

3) Tables break, float, or vanish in the generated PDF

What it looks like: A table splits mid-row, appears at the end of the document unexpectedly, overlaps text, or becomes unreadable.

What typically causes it:

• The PDF builder is interpreting tables as images or as complex Word objects
• Tables are embedded as pasted spreadsheets with merged cells and nested formatting
• Table captions are not linked or are placed inconsistently relative to the table

What usually works:

• Convert tables to simpler structures (avoid excessive merging, nested tables, and embedded objects)
• Ensure each table has a consistent caption format and numbering
• Where the journal allows separate table files, upload them as individual table files rather than embedding them inside the main text (only if the journal instructions support that workflow)

How to correctly order files for PDF auto-generation (so tables and figures behave)

PDF builders generally behave best when the submission package has a predictable hierarchy: a clear “main manuscript” plus discrete, consistently labeled supporting components. However, EM and S1M can assemble files differently depending on journal configuration. That makes file order and item type labeling more important than many researchers realize.

A stable ordering strategy that works in most configurations

When the journal allows multiple file uploads to assemble a combined PDF, a conservative sequence is:

1. Main manuscript file (Word or LaTeX main source, as required)
2. Tables (if submitted separately, one file per table or one consolidated tables file—follow journal rules)
3. Figures (one file per figure, numbered consistently)
4. Supplementary files (appendices, additional methods, datasets, reporting checklists)

The goal is not aesthetic preference. It is to prevent the PDF generator from placing tables and figures unpredictably, or appending them in a confusing order that reviewers must fight through.

File labeling and naming conventions that reduce conversion errors

• Use simple filenames: Manuscript.docx, Table1.docx, Figure2.tif, SupplementaryMethods.pdf
• Avoid special characters and long strings: no #, &, parentheses stacks, or version trails like FINAL_final_revised3
• Match in-text callouts precisely: “Table 2” in the text should map to a file named Table2…

A note on ZIP uploads (common in EM journal setups)

If the portal allows zipped uploads, it can save time, but it also increases the risk of incorrect item types after unpacking. In EM, journals may expect authors to correct item types post-unpack and can support batch item-type changes.

How to verify the final HTML proof before approving submission

Many authors treat the final proof step as a quick visual scan. That is risky because conversion errors often affect exactly what editors and reviewers see first: the title page, abstract, headings, tables, figure callouts, and references. A structured review takes only a few minutes and can prevent avoidable resubmission requests.

What to check in the HTML proof (and why it matters)

1. Title, author list, and affiliations
   Confirm spelling, order, and the corresponding author designation. Portal metadata can override what appears in the manuscript file.
2. Abstract and keywords
   Check for missing symbols, broken italics (e.g., species names), and truncated text, especially if the abstract was pasted into a form field.
3. Headings and section order
   Ensure headings did not collapse into plain text. If the journal uses automated screening, malformed structure can slow triage.
4. Tables (highest priority)
   Scroll every table start-to-finish:
   • Are columns aligned?
   • Are footnotes present and correctly linked?
   • Did any table split mid-row or lose shading that carries meaning?
5. Figures and captions
   Confirm each figure matches its caption and numbering. Look for swapped images, a surprisingly common conversion problem when multiple versions exist.
6. References and special characters
   Verify Greek letters, minus signs, superscripts, and diacritics. These often break when systems convert from Word or LaTeX to HTML or PDF.

A practical “two-format rule”

If the portal offers both an auto-generated PDF and an HTML proof, compare them side-by-side for the elements above. If the HTML looks correct but the PDF is broken (or vice versa), treat that as a signal that the source files need simplification or the upload types need correction before final submission.

Portal quirks that frequently trigger preventable delays

Editorial Manager: item type mismatches are a common root cause

EM’s flexibility is powerful, but it increases the chance of labeling mistakes. When figures are uploaded as the wrong type, or when the main manuscript is not tagged correctly, the system may build an incorrect combined PDF or route files improperly for editorial checks.

ScholarOne: validations can feel “late” and non-obvious

S1M workflows often feel smooth until the end, when the system surfaces missing declarations, contributor details, or file requirements. Planning for a final “metadata sweep” before clicking submit reduces last-minute surprises, especially for multi-author papers with complex funding and ethics statements.

How to decide which workflow to use when journals allow options

• If the paper contains complex tables, heavy math, or specialized symbols, a single author-generated PDF may be safer for first-pass review (if permitted).
• If the journal requires source files immediately, simplify formatting and keep tables and figures as clean, separate objects wherever possible.

Final takeaways: a research manuscript submission process that stays under control

Editorial Manager and ScholarOne both support rigorous publishing workflows, but each has predictable friction points. Researchers can reduce delays by treating research manuscript submission as a technical handoff: label files cleanly, upload in a stable order, and review the HTML or PDF proof with the same care used for the manuscript’s final pre-submission read-through.

When internal bandwidth is limited, or when repeated portal rebuilds are slowing progress, research teams often consider a specialized journal submission management partner. Enago’s Journal Submission Service can help researchers navigate portal-specific requirements, ensure compliance with journal instructions, and manage the upload and verification steps without derailing research timelines. If the main risk is technical non-compliance rather than content quality, Enago Reports’ Technical Check Report can also help identify frequent pre-submission issues across structure and formatting before the manuscript enters a portal workflow.

The post Editorial Manager and ScholarOne: Troubleshooting Common Submission Portal Glitches and Errors appeared first on Enago Articles.

For many researchers, the friction point is practical: the dataset is not ready to be fully public, the journal uses double-blind peer review, or the repository DOI is not yet active. This is where private reviewer links (also called “private links,” “reviewer links,” or “temporary sharing URLs”) become essential. This article explains how to navigate Data Availability Statement requirements during the journal submission process: selecting an appropriate repository workflow, generating reviewer-access links in repositories such as Figshare and Dryad, and writing a Data Availability Statement that editors can quickly verify before they send a manuscript for review.

Why Journals Ask for a Data Availability Statement (and What “Mandatory” Really Means)

A Data Availability Statement is a short section in the manuscript that tells readers and editors where the data supporting the results can be found (or why they cannot be shared). Increasingly, it also serves as a screening tool during submission: if the journal requires open data (or requires transparent disclosure), missing or vague statements can lead to avoidable delays, returned submissions, or desk rejections.

It is also important to recognize that “mandatory” has layers. Some journals mandate deposition of certain data types into specific community repositories. Others do not mandate sharing, but still require transparency about availability. Springer Nature explicitly positions its policy as requiring a DAS while acknowledging that not all data can be shared publicly (for instance, identifiable human participant data). PLOS, in contrast, generally requires authors to make data needed to replicate findings publicly available at publication, while allowing restrictions when legal or ethical rules prevent open sharing, as long as the DAS clearly explains the access pathway.

For authors trying to submit a paper to journal systems under tight deadlines, the practical takeaway is simple: the DAS is not “administrative filler.” It is a compliance artifact that editors use to judge whether the manuscript can proceed.

Decide the Right Data-Release Route Before Uploading Anything

Before generating links or drafting the DAS, authors typically benefit from a quick policy-to-workflow mapping. Most submission problems occur because the repository settings and the DAS are planned in isolation.

A workable decision sequence looks like this:

1. Confirm the journal’s data policy level (required DAS only vs required deposition vs required public release at submission vs at publication).
2. Check whether the journal uses double-blind review. If it does, the dataset landing page and files should not reveal author identities during review.
3. Classify the data as open, restricted, or non-shareable:
   • Open: can be shared publicly with appropriate licensing.
   • Restricted: can be shared with controlled access (e.g., via a data access committee, application process, or restricted repository).
   • Non-shareable: cannot be shared due to legal or ethical constraints; however, journals still expect transparent disclosure and, where feasible, a process for qualified access.

Springer Nature explicitly notes that reviewers may request access to data that are not publicly available, and that repositories can support peer-review access via private links that do not include author information, particularly relevant in double-blind workflows.

How to Generate Private Reviewer Links in Figshare (and What to Double-Check)

Figshare supports private links that allow access to files and metadata before the item is public, including for anonymous peer review. In Figshare’s user guide, the private link function is presented as a way to share unpublished or embargoed content privately (for example, during peer review), and it can also be configured with an expiration date.

A typical Figshare workflow during submission is:

1. Upload files and complete the item metadata as required by the repository or journal integration.
2. Use the item’s sharing controls to select “Share with private link.”
3. Configure expiration (optional) and copy the generated URL for the submission system.

Two details matter for compliance, and are easy to miss during a rushed journal submission process:

First, Figshare notes that people accessing the private link will see an anonymized version of metadata (author information removed). However, the files themselves may still contain identifiers (for example, institution names in file properties, author names in a readme, or acknowledgments in supplementary PDFs). Figshare explicitly warns that anyone with the private link can view and download files, so the files should be anonymized when needed for double-blind peer review.

Second, private links are not meant to be permanent scholarly identifiers. Figshare documentation and peer review guidance emphasize that private links support anonymous access during review, whereas the DOI (once public) should be used for the final, published record.

How Dryad Handles “Private for Peer Review” Links (and What “Temporary” Means)

Dryad offers a specific setting called “Private for Peer Review.” When selected, the dataset remains private while the associated manuscript is under peer review, and Dryad provides a private URL that supports double-anonymous download for reviewers and journal staff.

Dryad also clarifies a key distinction that directly affects how the Data Availability Statement should be written:

• The reviewer sharing link is a temporary URL that provides access to uncurated data during review and is not a permanent identifier.
• The dataset’s reserved DOI is permanent and will activate upon publication of the dataset.

This matters because many journals want a stable pointer in the final article. A strong submission workflow therefore uses (a) the private URL for peer review access and (b) the DOI once the dataset is released and published, updating the manuscript at the appropriate stage if the journal allows (often at acceptance or proofs).

Dryad also notes that submissions left in “Private for Peer Review” for one year with no activity may be withdrawn, which is another reason not to treat the peer-review link as an archival citation.

How to Format a Data Availability Statement That Editors Can Verify Quickly

Most journals do not require literary polish in a Data Availability Statement, but they do require precision. A strong statement answers, in a small number of sentences:

• What data are covered (raw data, processed data, code, materials).
• Where they are (repository name + persistent identifier such as DOI or accession number).
• When access applies (available now, available upon publication, under embargo).
• How access works if restricted (who controls access, what process, what conditions).
• Why data are not shared if applicable (privacy, consent limits, legal restrictions, third-party licensing).

Springer Nature’s guidance is explicit that a DAS should describe how to access data supporting the results, include persistent identifiers (e.g., DOI or accession number) when deposited in repositories, and explain when data cannot be shared openly (for example, participant privacy).

Repository-Based DAS Templates (Adapt as Needed)

1) Data Publicly Available Now (Best When Allowed at Submission)

The datasets generated and/or analyzed during the current study are available in [Repository name] at [DOI or accession number].

2) Data Deposited but Private for Peer Review (Double-Blind Workflow)

The data supporting the findings of this study have been deposited in [Repository name]. During peer review, editors and reviewers can access the files via the private reviewer link provided in the submission system. Upon acceptance/publication, the dataset will be made publicly available and will be accessible via [reserved DOI, if available].

This approach aligns with how repositories differentiate temporary reviewer links from permanent identifiers (e.g., Dryad’s temporary private URL vs reserved DOI).

3) Restricted Access Due to Ethics/Legal Constraints (But Access Possible)

The data are not publicly available due to [brief reason, e.g., identifiable human participant information and consent limitations]. De-identified data may be made available to qualified researchers upon reasonable request and with approval from [data access committee / institution / ethics board], subject to [data use agreement / IRB conditions].

This direction matches major journal policies that accept restrictions when justified, as long as the DAS clearly states the pathway for access.

4) Third-Party/Licensed Data (Authors Cannot Share)

The study analyzed data obtained from [provider] under license and the authors do not have permission to share the data publicly. Researchers may obtain access by applying directly to [provider] at [instructions or access page]. Any derived data that can be shared are available at [repository/DOI].

PLOS explicitly addresses third-party data limitations and expects authors to provide enough information for others to seek access.

Common Mistakes That Trigger Avoidable Back-and-Forth During Submission

Several issues repeatedly slow down the journal submission process, especially for early-career researchers navigating open-data requirements for the first time.

A frequent problem is using a reviewer-only private link as the final citation. Repositories and journal guidance generally treat reviewer links as temporary access mechanisms; final publication should point to a DOI, accession number, or stable landing page. Dryad is particularly explicit that the reviewer sharing link is not a permanent identifier and should be replaced by the DOI later.

Another common issue is double-blind leakage. Even when repository metadata are anonymized, file contents may expose authorship (for example, a methods appendix with institutional letterhead). Figshare explicitly warns that private-link recipients can see any identifying information within the files, so anonymization should be handled before sharing.

Finally, many Data Availability Statement drafts fail because they are overly generic, such as “Data available upon request,” without naming who controls access or what qualifies a request as reasonable. Policies increasingly expect specificity, particularly when restrictions apply.

A Submission-Ready Workflow: What to Finalize Before Clicking “Submit”

For researchers aiming to submit a paper to journal portals smoothly, a short pre-submit sequence can reduce compliance surprises:

1. Confirm the journal’s DAS wording requirements and whether the journal publishes the statement verbatim.
2. Deposit data in an appropriate repository (disciplinary if mandated; generalist if allowed).
3. If peer review requires confidentiality, generate a private reviewer link (Figshare private link or Dryad “Private for Peer Review” URL) and verify it opens without logging in.
4. Review files for anonymization if the journal uses double-blind peer review.
5. Draft the Data Availability Statement with a persistent identifier when available (DOI/accession) and clear conditions if not.
6. Place the reviewer link only where the journal requests it (often in submission fields, not in the main manuscript), and plan to update the DAS at acceptance if needed.

This is also where many authors benefit from practical research paper publication support. If the submission portal requires multiple disclosures and supplementary documents, a managed journal submission workflow can reduce returned submissions by ensuring all forms, declarations, and uploads align with the journal’s requirements. Enago’s journal submission assistance can help coordinate these compliance elements, especially when datasets, supplementary files, and policy statements must be aligned across systems.

Closing Perspective: Treat the DAS as Part of Research Transparency, Not a Last-Minute Formality

Data Availability Statements and repository linking have become integral to how journals operationalize transparency. When handled proactively, by aligning repository settings, private reviewer access, and a precise DAS, authors can reduce avoidable submission delays and keep editorial evaluation focused on the science.

Researchers preparing for a time-sensitive submission can also consider targeted support such as submission assistance to keep policy-driven details (including data statements and supplementary files) consistent across the manuscript and submission system, which can help streamline the overall paper submission process.

The post Data Availability Statement Requirements: Using Private Reviewer Links for Journal Submission appeared first on Enago Articles.