1. What is a Subassembly?

Subassemblies are one of the most flexible parts of Microvellum, allowing you to reuse a component — a drawer box, a door, a hardware group — across many products without rebuilding it each time.

That flexibility is derived from the subassembly being stored across several levels of data all at once, allowing one to save modifications and adjustments without disturbing the component everywhere else it is used. But understanding where changes are saved and which version is currently in use can be slightly confusing. This guide explains how subassemblies work, how Microvellum determines which one to use, and how to apply changes where they are desired without causing any undesired effects.

Always Remember: The most specific version is always prioritized. A change you make in one place stays in that place until you deliberately save it somewhere broader.

2. The Five Levels

Every subassembly lives at one of five levels. They run from the broadest — shared by everything — to the narrowest, which affects a single row.

3. Which Version You Get

When a product calls for a subassembly by name, Microvellum looks for it from the narrowest level to the broadest and uses the first one it finds:

1. Row

2. Product

3. Project — parent-specific

4. Project — shared

5. Library

If the search reaches the Library, Microvellum copies that Library version into your project as a new shared project version and uses the copy. From then on, the project has its own working copy. This happens automatically whenever there is no project version detected.

If nothing is found at any level, the subassembly cannot be copied and you will get an error. In practice that almost always means the name is misspelled or the item has not been added to the library you are using.

How names are matched

• Capitalization is ignored. DRAWER BOX and Drawer Box are the same subassembly.

• Spaces and underscores are interchangeable. Drawer Box and Drawer_Box are the same subassembly.

• When you save over an existing subassembly, the stored spelling updates to match what you just saved, so the name matches and updates to your most recent version.

• Multiple subassemblies of the same name can exist within one project, but within a single level, a name can only belong to one subassembly.

4. Saving Your Changes

Editing a subassembly changes only the version you were working on. Nothing moves to another level on its own- moving a change up or down in level is always a deliberate save.

There are three directions you can save, and each behaves differently.

Saving up covers row to product, row to project, and product to project. Saving down covers project to product, project to row, and product to row. Saving to the Library is a separate action and is covered in section 7.

What promotion does not do

Promoting a change does not clean up other, more specific versions elsewhere in the job. Those remain in place, because they are still more specific than the version you’ve just promoted. This includes subassemblies already placed into products, for instance.

Example:

Row 3 of Cabinet A has its own drawer box. You promote it to project level so the whole job uses it.

Cabinet B already had its own product-level drawer box. Cabinet B keeps using that one. Only the parts of the job with no override of their own pick up your promoted version.

This is expected behavior, not an error. If you want those overrides gone, revert them individually.

What overriding does not do

Saving down leaves the original untouched, remaining that way to ensure it can be reverted based on it for every other product and row. If you later want the narrower version to serve the whole job, promote it.

5. Subassemblies Inside Subassemblies

A nested subassembly is one used inside another subassembly rather than directly in a product. Nesting goes one level deep: product, then subassembly, then nested subassembly.

At project level, a nested subassembly takes one of two forms:

• Shared — used everywhere in the job, like any other shared project subassembly.

• Parent-specific — attached to one parent subassembly and used everywhere that parent appears, overriding the shared version.

A nested subassembly can be saved at project, product, or row level, regardless of the level its parent is on.

How nested subassemblies follow their parent

NOTE: Parent-specific nested subassemblies are project-level features. The Library stores subassemblies on their own, without parent-specific children.

6. Reverting

Reverting deletes the version you are currently using so that the next broadest version takes over. It does not copy or move anything down, it simply removes the override you no longer want.

Because of that, you can only revert when something broader exists to fall back on.

If revert isn't available: A subassembly you created new inside a project may have no Library counterpart, which means there is nothing to fall back to. Saving it to the Library first gives it that fallback and makes revert available. As such, it is recommended to save new subassemblies to the Library, if you intend to use them beyond their current project.

7. Saving to the Library

Saving to the Library updates the master version used by future projects — and by current projects if they revert back to it. It does not change the working copy in the project you are in.

A Library subassembly is identified by its name together with the library it belongs to, so the same name can exist in a different library without conflict. Project-specific details are cleared when the subassembly is saved to the Library — what is stored is the component itself, not where it happened to be used.

8. Save as New

Save as New creates an independent copy under a new name. The original is never consumed or altered, and the copy follows all the same rules from then on.

The name you choose must be genuinely unused — no other subassembly drawn from the same library, or living in the same project, may already be using it. If the name is taken, the save is rejected and Microvellum reports where the conflict was found.

Why a name conflict is not offered as an overwrite

A subassembly's name is its identity. Reusing an existing name would not create a separate copy — it would enroll your new version into the existing subassembly's hierarchy, which is the opposite of what Save as New is for.

If you actually want the existing subassembly, reference it by name in the normal way instead of using Save as New. If you want a separate one, choose a different name.

A name that is refused becomes available again if the subassembly currently using that name is later deleted.

The two modes

Repointing is never automatic outside of the first mode. If a save fails partway through, the previous name is restored so the operation leaves your work untouched.

9. Quick Reference

Common tasks and the level each one belongs at.