SolidWorks PDM

Beginner’s Guide to SolidWorks PDM Administration

A PDM administrator protects engineering data while keeping workflows simple enough for users to follow.

Core responsibilities

  • Manage users, groups, and permissions.
  • Maintain workflows, states, and transitions.
  • Control revision schemes and file templates.
  • Coordinate backups and disaster recovery.
  • Support users and document standard procedures.
Hub diagram with PDM Admin at the center connected to five responsibility areas: users and permissions, workflows and states, revisions and templates, backups and disaster recovery, and user support and documentation.
Everything routes back through the vault admin — plan for all five areas, not just the software.

The PDM vault uses a SQL Server database to store metadata: file names, folder structure, users, groups, permissions, workflow states, variables, references, and records of which versions exist — not the files themselves. The Archive Server stores the physical file versions, the actual CAD documents. The vault view in Windows Explorer is a client that talks to both. Every one of the five responsibility areas above ultimately touches that pair, which is why admin problems tend to cascade: a permissions mistake affects who can reach files, a workflow mistake affects what state those files can move into, and a backup mistake can affect whether either the database or the archive is recoverable at all.

How the vault actually works

The distinction above matters in practice. SOLIDWORKS never edits a file sitting on the Archive Server — it edits a copy pulled into a local vault cache on the user's PC.

Flow diagram from the Archive Server, through a Get Latest or Check Out step, into a local vault cache on the user's PC, which is what SOLIDWORKS actually opens and edits.
A stale local cache — not a stale vault — is usually why someone swears they have the latest version and don't.

Check Out gives one user the controlled editing lock on a file in the vault. Other users can normally still view or open it read-only, but they can't check it out for modification until the first user checks it back in or releases the lock. Get Latest Version refreshes the local cache to match what's actually in the vault without taking the lock — a step people skip because they assume their cached copy is automatically current, which it isn't. Undo Check Out releases the lock and discards local changes without creating a new version, which is the right move when a check-out was accidental or the edits shouldn't be kept.

Versions vs. revisions

These two terms get used interchangeably by newcomers, and that's worth correcting early.

Comparison diagram. Left column: Version 1 through Version 4, created automatically on every check-in. Right column: Rev A through Rev C, fewer in number, set manually as a file is approved through the workflow.
A file can sit at Version 12 while it's still only Rev B — the two counters move independently.

A version is created automatically every time a file is checked in — a raw change counter set by the server, with no approval attached. A revision is a formal milestone, usually set manually as a file moves through workflow approval, following a revision scheme the administrator configures (alphabetic, numeric, or a major/minor combination). Don't confuse the two: a part with dozens of versions might still be sitting at Rev A if it hasn't been through the approval workflow yet.

What to learn first

Start with vault structure, check-out and check-in behavior, versions and revisions, references, data cards, workflows, permissions, and backup verification.

Vertical flow diagram of seven learning steps in order: PDM architecture, check-out and get latest version, versions versus revisions, references, data cards and variables, workflows and permissions, and backup verification.
How the vault works and how files move first — workflows and permissions only matter once that foundation is solid.

Learn vault structure and check-in/check-out behavior first because they form the foundation everything else sits on — folder structure, numbering conventions, variables, and workflows become increasingly painful to restructure once a vault has thousands of files in it. Data cards display PDM variables associated with files and folders; those variables can be mapped to SOLIDWORKS custom properties, so information like part number, description, material, and revision can flow between PDM and the CAD file. For example, a PDM variable such as Part Number can be mapped to a custom property, which can then be displayed automatically in a drawing title block — the mapping is what does the work, not the card by itself. References describe relationships between files, such as an assembly referencing its parts or a drawing referencing a model. PDM uses those relationships when displaying, retrieving, checking out, copying, and changing the state of related files, but a parent check-out or state change doesn't automatically cascade to every child — that behavior depends on reference dialog settings, transition rules, and what the user selects, all of which an administrator can control. Workflows and permissions come last for a reason: they only matter once the data underneath them is organized enough to have states and access levels worth defining.

Important rule

Test changes in a safe environment before applying them to the production vault.

Two-lane diagram. Top, correct: a change goes to a test or sandbox vault, gets validated, then reaches production. Bottom, wrong: a change goes directly to the production vault with no testing step.
A few minutes of testing can prevent hours of troubleshooting in the production vault.

Backup is the piece most new admins underestimate. The database and archive should be backed up together so they represent a consistent state — restoring mismatched backups can result in missing file versions or inconsistent vault information, even without anything being technically corrupted. That same instant, global effect is why workflow, permission, and card changes get tested in a sandbox first: those changes apply to everyone with access the moment they're saved, and a bad one during business hours doesn't inconvenience a single user — it can lock out the floor.

Sources

This article draws on SOLIDWORKS PDM's own documentation and official SolidPractices guidance for the architecture, versioning, and reference-handling details above: