EngineeringMechanical EngineeringOperations
SOLIDWORKS Automation: Macros, API & Task Scheduling
Automation is the most rewarding and most quietly hazardous thing a CAD administrator does. It removes real drudgery, and it creates a dependency on code that is rarely documented, seldom version-controlled, and frequently understood by one person.
- Group · Operations
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 17 min
01 Where Automation Earns Its Place
Automation is the most rewarding and most quietly hazardous thing a CAD administrator does. It removes real drudgery, and it creates a dependency on code that is rarely documented, seldom version-controlled, and frequently understood by one person.
The test for whether something should be automated is not whether it can be. It is whether the task is repetitive, rule-governed, and stable enough that the automation will still be correct in two years — and whether the organisation can maintain it when the person who wrote it is unavailable.
Automation that fails this test does not merely waste effort. It becomes a hidden dependency in a production process, and its failure after an upgrade is discovered at the worst moment by someone who does not know it exists.
Programming interfaces, scripting language support and task scheduling capabilities change between releases, and some capabilities are available only at the upper data management tier. Verify what is available for your release and tier before designing an approach.
02 Levels of Automation
| Approach | Effort | Durability | Suits |
|---|---|---|---|
| Recorded macro | Minutes | Brittle | One-off repetitive tasks; a starting point for something more considered |
| Edited macro | Hours to days | Moderate | Recurring internal tasks with variable inputs — batch export, property population |
| Standalone application | Days to weeks | Good, if maintained | Business-critical automation, integrations, anything with a user interface |
| Scheduled batch task | Hours | Good | Unattended overnight work — conversions, exports, drawing updates |
| Vault transition action | Minutes | Very good | Setting variables, incrementing revision, notifying — configuration rather than code |
| Vault-side scripted hook | Hours to days | Moderate | Automatic actions on vault events; upper tier only |
| Programmatic integration | Weeks | Depends on both ends | ERP and business system exchange; upper tier only |
Where a vault transition action can achieve the outcome, use it rather than writing a script. Configuration survives upgrades far better than code, is visible to anyone with administrative access, and does not depend on a language runtime or a programming interface that may change.
A surprising proportion of what administrators write scripts for — setting properties, incrementing revision, moving files between folders, sending notifications — is available as workflow configuration.
03 Worthwhile Targets
The tasks that reliably repay automation share a shape: high volume, rule-governed, error-prone when done by hand, and stable over time.
Batch export
Generating neutral geometry and fixed-layout drawings across a released set, for transmittal or long-term retention.
Why it pays: high volume, entirely rule-governed, and skipped when manual.
Property population
Applying or correcting custom properties in bulk, particularly during migration or after a schema change.
Why it pays: the only practical way to correct a schema across thousands of files.
Standards checking
Verifying that documents conform — required properties present, correct template, material assigned, units correct.
Why it pays: catches defects before release rather than after issue.
Drawing and view generation
Creating standard drawing sheets and views for families of similar components.
Why it pays: removes repetitive setup while leaving detailing to the engineer.
Bulk conversion
Opening and resaving a large set after an upgrade, or converting legacy files ahead of migration.
Why it pays: unattended overnight work that would otherwise block engineers.
Business system exchange
Pushing item and structure data from the vault into an ERP or reading requirements back.
Why it pays: eliminates re-keying, which is where bill of materials errors originate.
Anything involving engineering judgement. Automated dimension placement, automatic tolerance assignment, or scripted design decisions produce output that looks authoritative and has not been thought about. The failure is worse than doing it by hand, because nobody reviews what the machine produced.
Also avoid automating around a broken process. A script that corrects properties on release is treating a symptom; the cause is that the properties were not required at creation, which is a data card and transition condition problem.
04 Unattended Batch Work
Task scheduling runs work overnight against files nobody is using. It is the natural home for conversion, export and reporting, and it has requirements that catch people out.
- A dedicated service account. Not a person's account. When they leave or change their password, every scheduled task fails silently.
- Entitlement availability. Unattended work consumes an entitlement while it runs. In a small pool, an overnight batch that overruns into the morning blocks an engineer.
- Vault access under that account. The service account needs its own vault credentials and appropriate permissions, and its actions appear in history under that identity — which is desirable, since automated changes should be distinguishable from human ones.
- A dedicated machine where volume justifies it. Batch work on a workstation competes with whoever uses it.
- Failure reporting. A task that fails at 2am and reports to nobody has not run for six weeks by the time anyone notices.
- Bounded runtime. A batch that grows with the data set will eventually overrun into working hours. Monitor duration, not just success.
Where a scheduled task modifies files in a vault, those modifications appear in version history and may increment versions. If the task runs nightly over a broad set, it can generate substantial archive growth and a history full of changes nobody made.
Scope batch modification narrowly, run it only against files that actually need it, and ensure the service account identity makes automated changes obviously distinguishable from human ones in the history.
05 Automation Is Software
The single most consequential point on this page. Automation written by an administrator is production code in a production process, and the absence of software discipline around it is the source of nearly every problem it causes.
Minimum discipline
Non-negotiable
- A named owner, distinct from whoever wrote it, responsible for it continuing to work.
- Stored in one controlled location, in backup scope, not on someone's desktop.
- Version history, even if only dated copies with a change note. Knowing what changed and when is what makes a regression diagnosable.
- Documentation: what it does, what it assumes, when it runs, and how to disable it safely.
- An inventory: every piece of automation in service, listed in the standards register.
Strongly advisable
- A test data set the automation can be run against safely.
- Dry-run capability for anything that modifies files, reporting what it would change without changing it.
- Logging of what was processed and what failed, retained long enough to investigate.
- Graceful failure — stopping cleanly rather than half-completing a batch.
- A stated review date, so unused automation is retired rather than accumulating.
The most common automation failure is not technical. An administrator writes something useful, it becomes embedded in daily work, and they leave. Nobody else knows what it does, where it runs, what it assumes, or whether it can be safely disabled — so it is left alone until it breaks after an upgrade and takes a process down.
Documentation and a named owner are what prevent this, and both cost a fraction of the effort that writing the automation did.
Security
Macros are executable code with the privileges of whoever runs them. Two consequences follow. Automation obtained from outside the organisation should be reviewed before use, not merely trusted because it came from a plausible source. And where macros are distributed to engineers, they should come from the controlled location with restricted write access — a shared folder where anyone can place a macro is a distribution channel for anything.
06 Automation Across Upgrades
The recurring cost, and the one most often omitted from upgrade planning.
Programming interfaces change between releases. Methods are deprecated, behaviour is refined, and object models evolve. Automation that worked in one release may fail in the next — and the failure is frequently silent rather than obvious, producing incorrect output rather than an error.
| Stage | Action | If skipped |
|---|---|---|
| Upgrade planning | Enumerate every piece of automation in service from the register | Something undocumented breaks and nobody knows it existed |
| Validation | Run each against the target release in a non-production environment | Failures discovered in production, mid-rollout |
| Validation | Verify output correctness, not merely that it completed | Silent behavioural change produces wrong results that look right |
| Remediation | Fix or retire before the rollout begins | Rollout halted while automation is repaired under pressure |
| Post-upgrade | Run each in production and confirm output | A scheduled task fails overnight and is noticed weeks later |
Not every piece of automation is worth carrying forward. Where a script was written for a problem that no longer exists, or where the effort to make it work on the new release exceeds the value it delivers, retiring it is the right decision.
Making that a conscious decision at each upgrade prevents the slow accumulation of automation nobody uses but everybody is afraid to remove.
07 Build or Buy
Commercial add-ins exist for most common automation needs — batch export, standards checking, drawing generation, business system integration. The choice between building and buying turns on maintenance rather than on initial cost.
Build when
- The requirement is specific to your process and no product addresses it.
- The task is simple enough that maintenance is genuinely low.
- You have more than one person able to maintain it.
- The automation is convenient rather than business-critical.
Buy when
- The automation would be business-critical — its failure stops work.
- The vendor commits to certifying against each annual release.
- The requirement is common enough that a product exists and is maintained.
- Your team has no capacity to maintain code alongside its actual work.
The honest comparison is not licence cost against development time. It is licence cost against development time plus annual re-validation, plus the fix effort when an interface changes, plus the risk that the only person who understands it leaves.
For anything business-critical, a maintained commercial product is frequently cheaper over its life than the equivalent built internally — and the maintenance obligation transfers to someone whose job it is.
08 Automation Checklist
- Inventory maintained. Every piece of automation in service listed in the standards register.
- Named owner per item. Responsible for it continuing to work, distinct from whoever wrote it.
- Stored centrally and backed up. One controlled location with restricted write access, in backup scope.
- Version history kept. Dated copies with change notes at minimum.
- Documented. What it does, what it assumes, when it runs, how to disable it safely.
- Configuration preferred over code. Vault transition actions used where they achieve the outcome.
- Judgement not automated. Nothing produces engineering decisions without review.
- Service account for scheduled work. Dedicated account with its own vault credentials, not a person's.
- Failure reporting in place. Scheduled tasks report failure and duration to someone who will act.
- Entitlement impact considered. Unattended work does not exhaust a small pool during working hours.
- Automated changes identifiable. Service account identity distinguishes them in vault history.
- Dry-run available. Anything that modifies files can report what it would change first.
- Validated at every upgrade. Run against the target release with output correctness verified, not just completion.
- Retirement considered at each upgrade. Unused or uneconomic automation removed deliberately.
- External code reviewed. Automation from outside the organisation examined before use, and distributed only from the controlled location.
09 Frequently Asked Questions
Should engineers be allowed to write their own macros?
For personal productivity, yes — a macro that speeds up someone's own repetitive task is straightforwardly useful and nobody else depends on it. The line is reached when other people start relying on it, at which point it has become production code without ever being treated as such.
The workable arrangement is a personal space where anything goes, and a controlled shared location with restricted write access for anything others use. Moving a macro from the first to the second is a deliberate step that brings ownership, documentation and upgrade validation with it.
We inherited automation nobody understands. What do we do?
Start by establishing what depends on it rather than by reading the code. Find out what it produces, who consumes that output, and whether anything downstream would notice if it stopped. That determines how carefully it needs handling.
Where it is genuinely critical and genuinely opaque, treat replacement as a project rather than reverse-engineering it under pressure at the next upgrade. Where nothing downstream depends on it, disabling it and waiting to see whether anyone complains is a legitimate and often quickest way to find out what it was for.
Our overnight batch job sometimes runs into the morning. Does it matter?
Yes, on two counts. It holds an entitlement while running, which in a small pool blocks an engineer arriving for work. And it may be modifying files that people are trying to open, producing check-out conflicts that appear as unexplained faults.
Monitor duration rather than only success, because a batch that grows with the data set will eventually overrun even if it completes cleanly today. Set a bound: if it has not finished by a defined time, it stops and reports. That converts a silent creeping problem into a visible one.
How much automation is too much?
The practical limit is the maintenance the organisation can genuinely sustain. Each piece requires validation at every annual upgrade, and that obligation is permanent. Ten scripts is ten validations a year, indefinitely.
A useful discipline is to review the inventory annually and require each item to justify itself: is it still used, does it still save more than it costs to maintain, and is there now a configuration or commercial alternative? Automation that cannot answer those is a liability rather than an asset, and removing it is progress.
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.