Single vs. Multi-Document Design

A. Single-Document Design

Single-document design: all subsystems in one document

Pros

• Simple — Everything is in one document; no need to switch between multiple documents
• Great for small teams — Teams of 1-3 people can manage it easily
• Easy internal references — Parts within the same document can reference each other without cross-document operations

Cons

• Gets slower as it grows — Loading and operations slow down with many parts
• Requires coordination for multi-user editing — Although Onshape supports real-time collaboration, concurrent edits in a single document require good communication
• Not ideal for very complex robots — May lag with hundreds of parts

Pro Tip: Link Tab

In a single-document design, you can use the Link Tab app to embed external web content into your Onshape document (such as gear calculators or reference materials). This keeps all related information in one place.

Embedding external web content into your document via Link Tab

Link Tab appears as a tab at the bottom of the document, just like any other tab

Real Example: FRC Basketball Robot

This is a typical single-document design case. All subsystems (Drivetrain, Intake, etc.) are organized in different tabs within the same document.

B. Multi-Document Design

Multi-document design: each subsystem in its own document, referenced by a top-level assembly

Pros

• Each subsystem is independent — Modifying the drivetrain won't affect the intake document
• Parallel work — Different people work on different documents without interference
• Faster loading — Only open the subsystem documents you need

Cons

• More complex management — You need to maintain references between multiple documents
• Naming conventions are critical — Without good naming, managing many documents gets chaotic
• Cross-document references — You need to understand Onshape's inter-document referencing mechanism

Real Example: PTC Multi-Document Robot Project

This project splits the robot into multiple independent documents — one for each subsystem — and then references them all in a top-level assembly.

C. Recommendations

Regardless of which approach you choose, the most important thing is to stay consistent. Switching organization methods mid-season is costly. Discuss with your team at the start of the season, then commit to it.