Home / Blog / PDM
PDM health

12 Signs Your SOLIDWORKS PDM Vault Needs a Health Check

Slow searches are only one symptom. The larger risks appear when users cannot trust revision, references, automation, recovery, or who is allowed to change what.

Direct answer

When does a SOLIDWORKS PDM vault need a health check?

Run a health check when failures repeat, confidence falls, or a major environment change is approaching. Warning signs include rising login or connection errors, slow routine operations, missing references, stuck workflows or tasks, permission workarounds, uncontrolled files outside the vault, backup uncertainty, capacity pressure, and upgrades that cannot be planned from known evidence.

This page is for

PDM administrators, engineering leaders, IT teams, and manufacturing users deciding whether a problem is isolated, systemic, or an upgrade and recovery risk.

Implementation boundary

Do not make untested SQL, registry, archive, permission, or workflow changes in production. Collect evidence first, preserve recoverability, and use qualified support for environment-specific remediation.

Symptoms point to different layersA health check separates client, network, service, database, archive, configuration, and process causes.Symptoms point to different layersClientversion, cache,add-insNetworkname, latency,connectivityServicesarchive, DB,licensesDataSQL, archives,capacityProcessworkflow, rights,adoption
A health check separates client, network, service, database, archive, configuration, and process causes. Original Morphos 3D planning diagram.

The twelve signs worth investigating

One slow morning does not prove a vault-wide defect. Repeated patterns across users, sites, files, or workflow steps do. Record who was affected, what action was attempted, when it happened, how long it took, what error appeared, and whether the same task worked elsewhere. That turns frustration into a reproducible case.

Several warning signs create direct control or recovery risk and should outrank convenience problems. If backup coverage is unknown, archive capacity is near a limit, released data can be changed through a permission gap, or users routinely bypass the vault, stabilize those conditions before spending time on cosmetic tuning.

SignWhat it may exposeFirst evidence
1. Repeated login or vault-connection failuresIdentity, name resolution, services, ports, or version problemsClient log, time, user, machine, server reachability
2. Routine browse, search, get, check-in, or transition operations slow downClient, network, SQL, archive, indexing, capacity, or add-in bottlenecksTimed baseline by action, user, site, and file set
3. Assemblies open with missing or unexpected referencesSource hygiene, cache, search paths, migration mapping, or duplicate namesReference report and reproducible assembly package
4. Users retrieve or release the wrong revisionWorkflow, revision, state, permission, training, or duplicate-authority failureFile history, state, card, user steps, and released output
5. Automated convert, print, or other tasks queue, fail, or driftTask host, permissions, application version, configuration, or input qualityTask logs, host status, failing files, and recent changes
6. Workflows contain abandoned states or unclear transitionsProcess drift and exception workaroundsWorkflow map, transition history, and process-owner review
7. Permission requests and Admin interventions keep risingGroup design, inheritance, role ambiguity, or workflow mismatchRequests by role, path, state, and required action
8. Engineers or programmers save active work outside the vaultPerformance, training, missing file classes, workflow friction, or trust lossSample paths, reasons, and downstream impact
9. Search depends on knowing the folder pathIncomplete cards, inconsistent variables, indexing, or poor search designCommon search cases and field completeness
10. Backup jobs exist but nobody can show a restore testUnproven recovery and ownership gapsComponent list, job logs, recovery-point manifest, restore report
11. Archive, SQL, cache, or task-host capacity keeps approaching limitsGrowth, retention, maintenance, or infrastructure mismatchTrend by component, free space, database statistics, and alert history
12. An upgrade or server move begins without a current baselineUnknown compatibility, customization, and recovery riskVersion inventory, add-ins, integrations, test plan, and complete backup

Build a baseline before changing the system

A baseline should record PDM server and client versions, service packs, SQL version, archive roots, server components, vault size, file and version counts, active users, sites and replication, add-ins, task hosts, indexing, storage trends, backup status, and recent infrastructure or policy changes. The official support-information wizard can collect archive logs, database statistics, application versions, registry data, installed add-ins, client logs, and environment details. If it generates a SQL backup, that backup is not included in the support ZIP and must be copied separately.

Add user-level test cases that matter to the business: log in, browse a common folder, search by part number, get a released assembly, check out and check in a known test file, change state in a test path, and complete an automated task. Record the time and expected result. These tests become the verification set after each controlled correction.

Keep the baseline read-only and time-stamped. If the environment changes during diagnosis, record who changed what, why, and how it was validated. Multiple simultaneous fixes make it impossible to know which change helped or introduced the next failure.

Admin access can hide the actual defect

Reproduce problems using the affected role and workstation when safe. An administrator may bypass the permission, cache, or workflow condition that blocks ordinary users.

Capture the baseline before the first corrective change

The downloadable log records the user, site, releases, exact action, test object, expected and actual result, elapsed time, error evidence, comparison case, business impact, controlled change, rollback, retest, and owner.

Download the PDM health baseline CSV

Separate incident response from health improvement

If users cannot retrieve production data, released information is wrong, archive or database integrity is uncertain, or recovery is at risk, treat the condition as an incident. Preserve logs and backups, limit changes, identify business impact, and engage the proper technical owners. Do not use a broad cleanup project as a substitute for stabilizing production.

A health improvement project is appropriate when patterns are chronic but controlled: searches are awkward, workflows accumulated old states, permissions require frequent manual changes, or task automation needs standardization. Define the baseline, select one problem class, test the correction outside production where appropriate, and compare the same user-level cases afterward.

Training problems and configuration problems can look identical. If a documented job-based procedure works for one trained user but not another, training or role clarity may be the first issue. If the same correct steps fail across users, investigate the environment. Record evidence rather than assigning blame from the first symptom.

1

Classify impact

Identify production stoppage, data-control risk, security risk, recovery risk, or routine friction.

2

Preserve evidence

Capture logs, exact errors, times, affected objects, versions, and recent changes before broad restarts or edits.

3

Reproduce and isolate

Compare users, machines, sites, roles, files, and actions to narrow the affected layer.

4

Change one controlled variable

Use a test environment where appropriate and maintain a rollback path.

5

Verify the business case

Repeat the same baseline test and confirm the user receives the correct data and authority.

Health-check decision pathStabilize recovery and production risk before tuning convenience or adding features.Health-check decision pathProtectbackup andrestore statusReproduceuser, file,time, actionIsolatelayer andscopeCorrectone controlledchangeVerifybaseline anduser outcome
Stabilize recovery and production risk before tuning convenience or adding features. Original Morphos 3D planning diagram.

What a useful PDM health check should review

The review should connect architecture, operations, and user behavior. Infrastructure scope includes SQL, archive and database services, storage, network paths, name resolution, license service, backups, monitoring, and version compatibility. Vault scope includes archives, database statistics, workflows, permissions, cards and variables, templates, add-ins, tasks, replication, indexing, and logs.

Business-process scope includes how revisions are created, who approves release, how manufacturing retrieves controlled outputs, what happens to rejected work, where supplier and customer data lives, and which files still bypass PDM. A perfect server cannot fix an undefined release decision, while a well-designed workflow cannot compensate for an untested restore.

The deliverable should rank findings by risk and evidence, not by the number of configuration observations. Each recommendation needs an owner, expected outcome, validation test, rollback plan, and dependency. Separate quick operational corrections from changes that require process approval, infrastructure work, or a dedicated upgrade project.

  • Current architecture, versions, supported combinations, and service health.
  • SQL and archive capacity, growth, maintenance, and performance evidence.
  • Backup completeness, monitoring, protected copies, and last isolated restore.
  • Workflow, revision, permissions, card variables, search, and user-role behavior.
  • Tasks, add-ins, indexing, replication, integrations, and customizations.
  • Files outside the vault, support patterns, training gaps, and ownership.

Turn findings into a controlled improvement queue

Prioritize recovery and data-control findings first, production reliability second, and convenience or enhancement work after the environment is stable. A critical finding might be an incomplete backup set or a permission path that can alter released data. A medium finding might be repeated task failures with a manual fallback. A lower finding might be a card field that could improve search but does not affect authority.

Close each finding with evidence. A storage recommendation closes when capacity and alerts meet the agreed threshold. A workflow change closes when affected roles pass release and rejection cases. A performance finding closes when the same timed baseline improves without changing the returned result. A recovery finding closes only after the isolated restore and business validation succeed.

Schedule the next review around meaningful triggers rather than waiting for user frustration: major PDM upgrades, SQL or server moves, authentication changes, new sites, replication changes, large migrations, new automations, and rapid vault growth. The objective is predictable operation, not a one-time score.

PriorityExampleClosure evidence
CriticalIncomplete recovery set or uncontrolled released-data edit pathProtected synchronized backup and passed restore, or permission case passed by role
HighProduction access failures, reference errors, or repeated automation stoppageReproducible case corrected and monitored
MediumChronic manual administration or search inconsistencyProcess owner accepts improved role-based test
PlannedNew metadata, workflow, report, or automation capabilityScoped change, test plan, approval, and release record

Frequently asked questions

What does a SOLIDWORKS PDM health check include?

A useful review covers versions and architecture, services, SQL and archive capacity, network behavior, logs, backups and restore evidence, workflows, revisions, permissions, cards, search, tasks, add-ins, replication, integrations, and real user workflows.

Why is SOLIDWORKS PDM suddenly slow?

Possible causes span the client, network, name resolution, archive and database services, SQL, storage, indexing, add-ins, replication, cache, and the specific file set. Capture timed reproducible cases by user, site, action, and file before changing the environment.

Can old PDM workflows be removed?

SOLIDWORKS PDM 2026 can archive workflows. Files cannot transition or roll back to another state while their workflow is archived, although the workflow can be unarchived later. Process owners should test historical access, reporting, and the operational effect before changing production.

When should a PDM health issue become a support incident?

Escalate when production data is unavailable, released information may be wrong, database or archive integrity is uncertain, recovery is at risk, or the issue has broad operational impact. Preserve evidence and avoid untested production changes.

Vendor references and method

  1. SOLIDWORKS 2026 Help: local PDM log file, official client event and connection evidence
  2. SOLIDWORKS 2026 Help: collecting support information, official archive, database, version, add-in, registry, and environment collection
  3. What is new in SOLIDWORKS 2026 PDM, current workflow, synchronization, encryption, authentication, and upgrade context
  4. SOLIDWORKS 2026 Help: archive workflows, official current workflow-archive behavior
  5. Checklists, sequencing, and decision gates on this page are Morphos 3D implementation guidance. Adapt them to the exact software release, infrastructure, machine, controller, quality system, and approved company procedures.

Bring evidence, not a vague slow-vault complaint

A useful starting packet includes exact user cases, logs, versions, architecture, recent changes, backup status, and one representative file set.

Request a PDM reviewCheck recovery readiness