SolidWorks Automation Guide — Macros, Add-Ins, Task Scheduler, and API Triggers

What SolidWorks Automation Actually Means

“SolidWorks automation” gets used for everything from a 20-line VBA macro that renames a file to a full production-grade COM add-in that processes 10,000 parts a night. Those are not the same thing, and the gap between them is measured in months of development, not hours.

This guide maps the territory. Four automation approaches cover almost everything teams do with SolidWorks programmatically. Each one has a ceiling. Knowing which ceiling you’re about to hit before you write code saves rebuilding the same solution twice.

The Four Approaches and Where Each One Stops

Most engineering teams should live in VBA macros and Task Scheduler until the ceiling becomes painful. The pain that pushes teams to add-ins is usually one of three things: the macro needs to handle errors reliably without user intervention; the macro needs to run hundreds of files without someone sitting at the keyboard; or the team needs something that other engineers can run without seeing code.

VBA Macros — Where Most Teams Start

The macro recorder in SolidWorks (Tools > Macro > Record) generates VBA code as you click through the interface. Run the recorded code to repeat the operation. This is where most SolidWorks automation begins.

What the recorder handles well:

• File export sequences (Save As, configure options, save)
• Custom property manipulation
• Drawing annotations
• Single-document operations on the currently open file

What the recorder silently fails to capture:

• Selection by name versus selection by click (the recorded coordinate is hardcoded; move the cursor and the selection misses)
• Events and notifications (you can’t record “wait for rebuild to complete”)
• Error conditions (the recorder produces code that assumes everything succeeds)
• Loops and batch operations over multiple files

Our SolidWorks macro recorder limitations guide documents exactly what gets omitted and how to add it back. The VBA vs C# API comparison explains when the VBA ceiling matters and when it doesn’t.

The VBA macro lifecycle in practice:

1. Record the operation you want to automate
2. Clean up the recorded code — remove hardcoded coordinates, add If...Then guards on null returns
3. Run it a second time manually to confirm it doesn’t rely on anything state-specific
4. Add a loop if you’re processing multiple files
5. Package it as a button in the SolidWorks toolbar via Tools > Customize > Commands

The mistake most engineers make is treating step 5 as optional. A macro that lives in a .swp file on someone’s desktop is infrastructure that disappears when they leave.

Common SolidWorks VBA automation workflows:

• Batch DXF flat pattern export: complete API walkthrough
• Drawing creation from part templates: automate SolidWorks drawing creation
• BOM export to Excel: native table vs macro approach
• Pack and Go with rename: Pack and Go API macro

The SolidWorks VBA API meters trap documents the most common mistake that causes silent wrong results in macros that work with dimensions: SolidWorks returns dimension values in meters, not millimeters, regardless of document units.

Task Scheduler — Batch Without Writing Code

Task Scheduler (Start > SOLIDWORKS Tools > SOLIDWORKS Task Scheduler, or launched from Tools > SOLIDWORKS Task Scheduler) lets you queue batch operations without writing any code. It handles:

• Batch convert files to DXF, DWG, PDF, STEP, IGES, STL, and other formats
• Update custom properties across a folder of files
• Run a VBA macro against a list of files
• Check files in and out of PDM Standard

For teams that need to process a batch of files on a schedule — nightly DXF exports, automated PDF releases, BOM property updates — Task Scheduler covers most of the use case without any API knowledge.

The limits:

Task Scheduler runs in a separate SolidWorks process. It cannot interact with an open SolidWorks session, and it cannot modify what it’s doing based on the content of the files it processes. If part A needs export option X and part B needs option Y, Task Scheduler cannot make that decision — everything runs with the same settings.

The other common issue: passing custom parameters into a VBA macro launched by Task Scheduler. There’s no native parameter-passing mechanism — the macro gets the file path and nothing else. The workaround is writing parameters to a temp file that the macro reads at startup, but this adds fragility. Our Task Scheduler parameter-passing guide documents this pattern and its failure modes.

When Task Scheduler is enough:

If your automation need is “process all files in folder X with these settings,” Task Scheduler is simpler and more reliable than writing equivalent code. Don’t build a VBA loop when the scheduler already does it.

When Task Scheduler isn’t enough:

• Logic that branches per-file (different settings for different part types)
• Operations that depend on assembly context (components, mates, configurations)
• Anything that requires interaction between files
• Error recovery (Task Scheduler logs errors but doesn’t retry or notify)

COM Add-Ins — Production-Grade Automation

A SolidWorks COM add-in is a DLL registered with Windows COM that SolidWorks loads at startup. It lives inside the SolidWorks process (SLDWORKS.EXE), has full access to the document model without file I/O latency, and can intercept events, add menu items, host Property Manager Pages, and run in the background while the user works.

Why not just make everything a macro:

Macros run out-of-process (in a separate VBA runtime) for standalone automation, or in-process via ISldWorks.RunMacro2 but without the event infrastructure. The in-process vs. standalone distinction matters for performance on large assemblies — decompilation of sldstepu.dll shows that STEP export calls PK_BODY_transmit directly in the SolidWorks process; running the same export out-of-process crosses a COM marshal boundary for every geometry call. For jobs involving 50+ files with complex geometry, that boundary adds up.

The more practical reason: add-ins can be distributed as compiled DLLs. Your colleagues don’t see .swp files, don’t accidentally edit the code, and don’t need to know anything about VBA. Installation is a registry entry or a SolidWorks add-in manager click.

When to make the jump:

The when to upgrade from macro to add-in guide covers this in detail, but the short answer: when users other than you need to run it reliably, or when the macro needs to handle events (document open, save, rebuild) without user action.

Architecture choices for SolidWorks add-ins:

SolidWorks’ COM architecture requires .NET Framework 4.x for registration as a COM object via regasm. If you want to use .NET 8 — modern C#, async/await, newer NuGet packages — the path is more complex and requires either EnableComHosting in the project file or a COM-entry-point shim. Our SolidWorks COM add-in with .NET 8 guide covers this in full.

CadShift is a SolidWorks COM add-in. The DXF batch export, BOM integration, and PDF export features in CadShift were originally VBA macros that hit the ceiling — specifically, the macro ceiling on reliable delivery to non-technical users and the Task Scheduler ceiling on per-file logic (different export settings based on sheet metal vs. solid body vs. weldment). The add-in approach solved both.

API Events — Reactive Automation

Event-driven automation responds to things happening in SolidWorks rather than being manually triggered. Open a document → automatically run a property check. Save → automatically increment revision. Rebuild completes → push updated BOM to a shared spreadsheet.

SolidWorks exposes events through the ISldWorks interface (FileNewNotify2, FileOpenNotify2, FilePostSaveNotify2) and through document-level interfaces (IPartDoc, IAssemblyDoc, IDrawingDoc), each with their own event set.

The event lifetime problem:

VBA macros cannot survive as persistent event listeners because the VBA runtime tears down when the macro finishes executing. A UserForm that never closes is the workaround — keeping the macro process alive — but it’s fragile and requires someone to leave a dialog open. Our SolidWorks VBA API events handler lifetime guide documents the UserForm pattern and why it breaks under certain conditions.

COM add-ins don’t have this problem. They stay loaded for the duration of the SolidWorks session and can maintain persistent event subscriptions.

The silent-failure problem with events:

SolidWorks event handlers that throw unhandled exceptions kill the event subscription silently — no error, no warning, the handler just stops firing. The API gotchas and silent failures guide documents this pattern and several others (null component references, SelectByID2 coordinate system mismatches, rebuild timing) that cause event-driven automation to fail without diagnostic output.

Automation for Specific Workflows

How to Build an Automation Roadmap for Your Team

Most teams don’t need to plan automation from scratch. The signal that something is ready to automate: an engineer is doing the same sequence of actions more than once a week and could write down the steps without thinking.

Phase 1 — Find the recurring tasks. Ask every SolidWorks user on the team: what do you do that feels like copying and pasting? DXF export, PDF release packages, BOM custom property updates, drawing title block fills, and revision incrementing come up in every manufacturing team we’ve talked to.

Phase 2 — Automate with the simplest tool that works. Start with Task Scheduler for batch jobs that have uniform settings. Use VBA macros for jobs that need per-file logic. Don’t build a COM add-in until Task Scheduler or macros hit their ceiling.

Phase 3 — Make it usable by non-engineers. A macro that only its author can run is a single point of failure. Package VBA macros into toolbar buttons. Package add-ins as a company-wide DLL installation. Document the one-line usage instructions. Our deploying macros to non-technical users guide covers the zero-setup distribution patterns.

Phase 4 — Treat automation as a product. Version-control your macros and add-ins (Git works fine; .swp files are text). Document what each tool does and what it won’t handle. Define who maintains it when the author leaves. A macro that nobody else understands has a useful life of one person’s tenure.

What CadShift Covers

CadShift is a production SolidWorks COM add-in purpose-built for the export automation workflows that appear most often in manufacturing teams: batch DXF flat pattern export, BOM integration with quantity tracking, PDF export with QR codes and watermarks, and consistent file naming based on custom properties.

It’s what you’d build if you spent the time to get the edge cases right — handling multi-body parts, mirrored configurations, non-sheet-metal thin parts, and per-layer DXF output without writing and maintaining the code yourself.

If you’re evaluating whether to build custom automation or use a purpose-built tool, our ROI analysis breaks down the comparison in terms of development time and ongoing maintenance cost.