Tech Tip: What is the Best Document Structure to Use in Onshape?

New users coming from file-based CAD systems often ask this question because Onshape’s cloud-native architecture allows users the freedom to arrange data in a multitude of ways. However, depending on what should be optimized, some data structures work better than others.

To choose between possible Document Structures, there are two core concepts to keep in mind:

1. Every Onshape Document gets the same resources on the server, and multiple tabs split those resources.

2. References, permissions, and releases are easier if you have one unified document.

Core Concept 1

Every Document Tab Shares the Total Maximum Document Resources

While documents scale dynamically on the server as needed, every tab in a document shares some slice of the total maximum allocated resources for this document. At a certain point, adding more tabs affects performance.

However, there is no limit to the number of documents you can have on the server. An easy way to grab more resources is to split large projects into multiple documents that reference each other in a hierarchy. This is probably our most common performance suggestion when customers are working with large assemblies:

At a project’s start during the R&D phase, it is fast and easy to start every project as a single large document that is referenced and shared.

As the design matures toward production, different teams might require access to different parts of the design, but not the whole. Splitting a single big document into multiple documents in a hierarchy grabs more server resources, but also gives you finer control over what subsets are shared and which sections are versioned or branched together.

Going one step further, this hierarchy can also include a master sketch that drives the part documents and sub-assemblies, which are then collected into a top-level assembly. This also benefits top-level assembly performance:

A good rule of thumb is to split up a document when it reaches approximately 40-100 tabs. When this is done, a helpful addition is to create an image similar to the one above, so that everyone on the team knows the relationship between the model and its constituent parts (sketches, drawings, features, etc). Sketching out your document structure on a whiteboard makes it crystal clear to everyone on the team how changes propagate.

However, what would keep people from splitting their 500-part assembly into 600 separate documents and drawings to try and make things perform at optimum efficiency? That would get you the most resources on the server, but you would also spend more time navigating between 600 documents versus 6. And that brings us to the second core concept:

Core Concept 2

References, Permissions and Releases all get easier if you have One Unified Document Containing Its Own References

Having each subassembly be its own self-contained document is a smart data structure if the team is spending a lot of time on Releases. Seeing the references between parts, sub-assemblies, and drawings becomes very simple for users if there are only two company-wide rules:

• Each part used in the subassembly is in a tab in that subassembly’s document.
• Each part’s drawing is also a tab in the subassembly’s document.

Now, there is nothing to search or hunt down.

Performance is also maintained, since the entire project is broken up into smaller documents.

In summary, no matter which document structure you choose, you should make sure it serves the human needs of your organization. Whether you are optimizing for the easiest sharing, the best large assembly performance, or the easiest release structure, Onshape’s document structures are flexible enough to meet your project’s changing needs:

If you have any questions about how your Onshape Document structure looks or what our CAD experts might suggest to improve your performance, contact us through the Help menu > Contact Support option at the top right along the Onshape toolbar.