EngineeringMechanical EngineeringStandards
SOLIDWORKS Toolbox & Design Library Governance
A standard hardware library generates component files on demand. That convenience is exactly what makes it dangerous when uncontrolled — every workstation generates its own, and the same nominal fastener ends up represented differently across the business, surfacing in the bill of materials rather than in the model.
- Group · Standards
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 17 min
01 The Highest-Risk Shared Library
A standard hardware library generates component files on demand, integrated with hole creation. That convenience is exactly what makes it dangerous when uncontrolled: every workstation generates its own, and the same nominal fastener ends up represented differently across the business.
The consequences arrive in the bill of materials rather than in the model, which is why they are usually discovered late. Three variants of the same bolt appear as three line items. A purchasing enquiry returns three part numbers for one component. An assembly opened on a different workstation reports missing references because the hardware it used does not exist in that machine's copy.
None of this is a fault in the library. It is the predictable outcome of a facility designed to generate content being installed, by default, locally on every machine.
Library configuration options and their locations change between releases. The governance principles here are stable; verify specific settings and interface paths against the documentation for the release in service.
02 Where the Library Should Live
| Location | Consistency | Version history | Access control | Verdict |
|---|---|---|---|---|
| Local, per machine | None | None | None | The default. Acceptable only for a genuinely single-user installation. |
| Shared network folder | Enforced | Backup only | Filesystem permissions | The workable minimum. Addressed by UNC path from every client. |
| Managed in a vault | Enforced | Full | Vault permissions | Best where a vault exists. Adds change history on the library itself. |
Addressing it consistently
Where a shared network folder is used, it must be addressed by UNC path — the same path string, from every workstation. A mapped drive letter is the recurring failure: one machine maps the share as one letter and another maps it differently, so hardware inserted on one workstation resolves to a path that does not exist on the other. The symptom is missing references that appear only for certain users, which is exhausting to diagnose because the file is plainly present.
Where the library is managed in a vault, clients reference it through their local vault view. The path is then consistent by construction, provided every engineer's vault view root is consistent — which is worth confirming rather than assuming.
The library path is a system option, so it is deployed and locked through the settings file in the administrative image. Setting it manually on each workstation reintroduces exactly the inconsistency the shared location exists to prevent, and will not survive a rebuild or a new starter. Set it once in the image, lock it, and verify after deployment by inserting a component and checking where it came from.
03 Configure Before Production Use
Several settings determine how generated components are named, numbered and described. Changing them after the library is in production means existing components and the new ones disagree.
Decisions to make first
- Which standards to enable. The library ships with several international standards. Enable only those actually used; disabling the rest reduces the browsing burden and prevents an engineer inserting a fastener from a standard the business does not buy to.
- Part numbering. How generated components are numbered, and whether that number aligns with the numbering used elsewhere. This drives the bill of materials, so it must match what purchasing and ERP expect.
- Descriptions. The description format that appears in bills of materials. Default descriptions are often not what a purchasing function needs.
- Configuration naming. How generated size and length variants are named. Once documents reference these names, changing the convention breaks the references.
- Custom properties. Which properties generated components carry, matched to the schema used across the rest of the estate so the bill of materials columns populate consistently.
- Which sizes are permitted. Restricting the available range to what the business actually stocks prevents an engineer specifying a fastener nobody can buy.
Every assembly referencing a generated component records the configuration name. Change the naming convention afterwards and those references no longer resolve, producing missing components across historical assemblies.
This is the setting most worth deliberating over before production use, and the one least amenable to correction later. Decide it with purchasing and manufacturing in the room, not as an administrative afterthought.
04 How Components Are Generated
A structural choice with significant downstream consequences, and one that many administrators are unaware they made.
Generated hardware can be produced in two ways. In one, each size and length variant is created as a configuration inside a shared master file — one file per fastener family, with many configurations. In the other, each variant is written out as a discrete file.
Configurations in a master file
The common default. Compact, and new variants appear without new files being created.
- Fewer files to manage and back up.
- Master files are written to whenever a new variant is generated, so write access is needed unless variants are pre-generated.
- All variants of a family share one file, so a vault holds one item with many configurations.
- A corrupted master file affects every variant in that family.
Discrete files per variant
Each generated size becomes its own file. More files, but each behaves like an ordinary component.
- Each variant can be vaulted, revised and permission-controlled independently.
- Integrates more naturally with an ERP item master where each fastener is a distinct item.
- File count grows substantially over time.
- Generally the better fit where the library is vault-managed.
Whichever mode is chosen, generating the commonly used range in advance — as an administrative task, once — removes the need for engineers to have write access to the library during normal work. Users then insert existing components rather than creating new ones, which is both faster and considerably safer.
Where an unusual size is genuinely needed, it becomes a request to the library owner rather than an unmanaged addition, which is the correct treatment for a change to a shared standard.
05 Permissions & Write Access
Uncontrolled write access is how a shared library stops being a standard. An engineer generating an unusual variant, or inadvertently modifying a master file, changes the library for everyone — usually without realising it and without any record of what changed.
The access model
- Engineers read; administrators write. Apply filesystem or vault permissions accordingly, and confirm they are actually enforced rather than merely configured.
- Set the read-only behaviour deliberately. The library carries a setting governing what happens when a write is attempted against a read-only file. Where the library is vault-managed or otherwise protected, this should be set to raise an error rather than silently clearing the read-only attribute and writing anyway.
- Use the library's own permission controls. In a multi-user environment, the library configuration includes access controls that operate above filesystem permissions. Enable them rather than relying on filesystem permissions alone.
- Refresh vault-managed content on log-in. Where the library sits in a vault, configure the cache to refresh at log-in so engineers see current content without a manual refresh.
The default behaviour when writing to a read-only document may be to change the read-only status and proceed. In a shared library that means filesystem permissions set to read-only are bypassed by the application itself, and the protection is illusory.
Set this to raise an error instead, and verify by attempting a write from an ordinary user account. Configuring permissions without checking this setting is one of the most common ways a library that appears governed is not.
06 Version & Upgrade Strategy
Upgrading the library upgrades it to the new major version. Workstations still on the previous release can then no longer use it, and the change is not conveniently reversible.
Two consequences follow, and both need to be planned before an upgrade rather than discovered during one.
- BeforeDecide the mixed-version positionIf any period will exist where releases are mixed, plan a separate library location per major version, with the version year in the folder name. Attempting to serve two releases from one library does not work.
- BeforeBack up the current libraryA customised library represents real accumulated work — enabled standards, numbering, descriptions, pre-generated variants. Verify the backup before touching it.
- DuringUpgrade once, centrallyPerform the upgrade deliberately as an administrative task on the shared library. Do not let it happen as an incidental side effect of the first client upgrade someone happens to run.
- DuringVerify configuration survivedConfirm enabled standards, numbering, descriptions and custom properties are intact after the upgrade. Configuration is not always carried forward completely.
- AfterTest insertion and the bill of materialsInsert hardware into a real assembly and confirm the bill of materials builds with the expected numbers and descriptions before releasing to the team.
- AfterConfirm historical assembliesOpen assemblies created before the upgrade and confirm hardware references still resolve. This is the check that catches a naming convention change.
Where the library path is set in the deployment image, the first client upgraded may offer to upgrade the shared library as part of its own installation. If accepted, the library moves to the new major version immediately — and every workstation not yet upgraded loses access, with no warning and no straightforward way back.
Sequence deliberately: upgrade one client, then the library, verify, then roll out. And take the backup first.
07 Design Library & Other Shared Content
The same governance applies to every other shared content location, and these are more often overlooked because they are smaller.
Design library
Reusable features, annotations, blocks, assemblies and parts dragged into documents. Grows organically and is rarely governed.
Control: shared location, restricted write access, a defined owner, and periodic review to remove superseded content.
Purchased component library
Supplier-provided models for bought-in items. Often imported ad hoc by whoever needed one first.
Control: a single controlled location with a defined naming and property standard, so purchased items behave like designed ones in the bill of materials.
Weldment profiles and cut lists
Structural section profiles used by weldment features, and the properties that drive cut lists.
Control: shared location, aligned to the sections actually procured, with cut list properties matching the wider schema.
Each shared content location should have a recorded authoritative path, a named owner and a date last reviewed. These locations accumulate quietly — a folder created for one project becomes a de facto library — and without a register nobody can say which is authoritative when two exist.
08 Library Governance Checklist
- Single shared location. Network folder addressed by UNC path, or a vault folder, referenced identically from every client.
- Path set in the image and locked. Deployed through the settings file, not configured per workstation.
- Verified after deployment. A component inserted on a sample machine demonstrably comes from the shared location.
- Configured before production. Standards enabled, numbering, descriptions, configuration naming and custom properties all decided.
- Naming aligned with purchasing and ERP. Part numbers and descriptions match what downstream systems expect.
- Size range restricted. Only sizes the business actually procures are available.
- Common range pre-generated. Engineers insert existing components rather than generating new ones during normal work.
- Write access restricted. Read for engineers, write for a named group, enforced at the filesystem or vault level.
- Read-only behaviour set to error. Verified by attempting a write from an ordinary user account.
- Cache refresh on log-in. Where vault-managed, clients see current content without manual refresh.
- Version strategy decided. Separate location per major version where any mixed-release period is anticipated.
- In backup scope. The library and all other shared content locations are captured by the backup regime.
- Registered. Every shared content location recorded in the standards register with an owner and review date.
09 Frequently Asked Questions
We already have local libraries on every machine. How do we consolidate?
Identify the machine whose library has been used most extensively — that copy contains the most generated variants and requires the least reconstruction. Take a copy of it as the basis for the shared library, configure it properly, place it in the controlled location and point every client at it through the deployment image.
Existing assemblies referencing local copies will need their references repaired. This is manageable in bulk but should be planned rather than left to individual engineers, because a repair done inconsistently recreates the divergence. Do the consolidation and the reference repair as one exercise, and take a backup of every local library before removing any of them.
Should we use the standard library at all, or model our own fasteners?
Both are defensible. The generated library is fast and covers a wide range, at the cost of the governance described here. A curated set of ordinary component files — one file per fastener you actually buy, with correct part numbers and properties — is simpler to control, integrates cleanly with an ERP item master, and behaves like any other component.
The curated approach suits businesses with a narrow, stable range of hardware and a strong item master. The generated library suits those needing breadth and variety. What does not work is using the generated library without configuring it, which combines the governance burden of the first with none of the control of the second.
Can the library be used offline?
Where it is vault-managed, the local vault cache serves this — content is available offline once cached, and refreshes on reconnection. Where it is a network folder, offline access requires a local copy, which reintroduces the divergence problem.
For engineers who genuinely work disconnected, the vault-managed arrangement is materially better. Where that is not available, the workable compromise is a read-only local copy synchronised from the shared location on a defined schedule, with the clear understanding that it is a cache and never the source.
Different projects need different fastener standards. How do we handle that?
Enable both standards in the one shared library rather than creating separate libraries. The library supports multiple standards concurrently, and restricting selection is better handled through guidance and drawing checking than through separate installations.
Separate libraries per project or customer is the pattern that reliably produces the consolidation problem three years later, because each acquires its own generated variants and its own drift. If selection genuinely must be constrained per project, do it through the design review process rather than by forking the library.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.