“SolidWorks automation” covers four distinct things that are often treated as interchangeable. They aren’t. A VBA macro that exports DXF files is automation. So is a Task Scheduler job that runs every night. So is a PDM Dispatch script that triggers on a workflow transition. So is a C# COM add-in with a custom Property Manager Page.

Each approach has a specific setup cost, maintenance burden, and capability ceiling. Picking the wrong one for a given workflow creates either an over-engineered solution or one that fails the moment requirements change. This guide maps the decision.

The Four Automation Approaches in SolidWorks

Understanding these four approaches is the foundation. A deeper look at the four levels of CAD automation covers the broader conceptual framework — this guide focuses on the practical decision of which tool to reach for first.

1. VBA Macros

A SolidWorks macro is a VBA script that runs inside a SolidWorks session via the macro recorder or the Tools → Macros menu. It has full access to the SolidWorks API through the ISldWorks COM interface.

Setup cost: Low. The macro editor is built in. No build chain, no deployment.

Capability ceiling: Medium. A macro runs in the active session and terminates when it finishes. It can’t listen to events between runs. It can’t survive an application restart.

When it makes sense:

  • One-time or occasional tasks: “Export these 80 parts to DXF before the meeting”
  • Tasks that require judgment mid-run (file selection, configuration picking)
  • Prototyping automation logic before committing to a full add-in
  • Single-user workflows where nobody else needs to run the same automation

When it breaks down:

  • The macro needs to run on a schedule without someone clicking “Run”
  • Multiple users need the same automation with different configurations
  • The task spans multiple SolidWorks sessions (open, close, reopen)
  • The automation reacts to model events (save, rebuild, change)

A functional DXF export macro looks like this:

Sub ExportFlatPatterns()
    Dim swApp As SldWorks.SldWorks
    Dim swModel As ModelDoc2
    Dim swPart As PartDoc
    Dim nRet As Long
    
    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc
    Set swPart = swModel
    
    Dim outputPath As String
    outputPath = "C:\Output\" & swModel.GetTitle() & ".dxf"
    
    swPart.ExportFlatPatternView outputPath, 1  ' 1 = flat pattern
End Sub

The full story on what this API call exposes — and where the entity type bitmask matters — is in the DXF entity export settings guide.

2. Task Scheduler

SolidWorks Task Scheduler is a separate add-in (C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS Task Scheduler\) that runs tasks on a Windows schedule without a manual SolidWorks session. It connects to SolidWorks in the background.

Setup cost: Low. No programming. GUI configuration only.

Capability ceiling: Bounded by the built-in task list.

What Task Scheduler can do:

  • Convert Files (DWG, DXF, IGES, STEP, PDF, eDrawings — all supported output formats)
  • Export Files (STL, DXF, PDF — same underlying SaveAs API call)
  • Update Files (custom properties, configurations)
  • Print Files (to any Windows printer)
  • Run Custom Task (calls a pre-built executable, not arbitrary code)

What Task Scheduler cannot do:

  • Create drawings from 3D models (no CreateDrawingDoc equivalent)
  • Open a part and intelligently decide what to export based on model properties
  • Write to PDM during the export run without custom task code
  • Do anything not in its built-in task list, including any multi-step conditional logic

For teams that need scheduled batch DXF or PDF from a folder of parts, Task Scheduler is the fastest working solution. Set it up once, point it at an input folder, set the schedule, and it runs. Automating SolidWorks file exports covers the Task Scheduler configuration in detail.

The thing engineers discover after setting up Task Scheduler: it doesn’t create drawings. Every time someone asks “can I automate drawing creation with Task Scheduler,” the answer is no. Drawing generation from 3D models requires code — see automating SolidWorks drawing creation for the macro approach.

3. PDM Dispatch Tasks

SolidWorks PDM (both Standard and Professional) includes Dispatch, a scripting tool that executes on PDM lifecycle events: file check-in, state change, approval, and workflow transitions.

Setup cost: Medium. Requires PDM administration access. Dispatch scripts are written in a custom language, not VBA or C#.

Capability ceiling: Medium-high. Dispatch can copy files, run executables, send email notifications, update PDM variables, and trigger external processes. It cannot directly call the SolidWorks API.

When Dispatch makes sense:

  • Triggering export jobs when a file moves to “Released” state in the PDM workflow
  • Sending email notifications to stakeholders on approval
  • Auto-incrementing revision numbers on a state transition
  • Copying released drawings to a read-only “approved” folder

When Dispatch breaks down:

  • You need to call the SolidWorks API (open the part, check geometry, export based on custom logic)
  • The task requires heavy logic that Dispatch scripting can’t express
  • You’re on PDM Standard (Dispatch is available in Standard but with fewer variables and triggers than Professional)

A Dispatch trigger that runs an executable on “Released” state:

Dispatch Task: Export on Release
Trigger: Transition to "Released"
Action: Run executable
Executable: C:\Tools\ExportTool.exe
Arguments: %FilePath% %RevisionNum%

The Export tool is a standalone CLI that calls SolidWorks API headlessly. This is the correct pattern for release-triggered export automation that needs real API access — not Dispatch itself, but a process Dispatch kicks off.

For the built-in export case (PDF generation from released drawings), the SolidWorks PDM Batch Plot guide covers the three methods: Batch Plot GUI, Task Scheduler for vault-wide runs, and API automation via Dispatch or add-in.

4. C# COM Add-In

A COM add-in is a .dll registered in the Windows registry that SolidWorks loads at startup. It has the same API access as a macro, plus persistent lifecycle methods: ConnectToSW, DisconnectFromSW, and event handlers that fire throughout the SolidWorks session.

Setup cost: High. Requires a C# project, COM registration, and either Installer or manual registry setup on each machine. The add-in lives in-process with SolidWorks.

Capability ceiling: Full SolidWorks API. No limitations.

When a C# add-in makes sense:

  • The automation must respond to events: file save, rebuild, model open, document close
  • You need a custom UI: toolbar buttons, menu items, Property Manager Pages
  • Multiple users on multiple machines need the same automation
  • The workflow is complex enough to require unit-testable code and a build pipeline

When a macro is sufficient:

  • The task runs once or occasionally on demand
  • One person runs it, on one machine, from the Tools → Macros menu
  • No UI integration needed beyond “Run this macro”

The detailed decision criteria for choosing between a macro and a full add-in is in when to upgrade from a SolidWorks macro to an add-in, including how in-process execution changes performance characteristics and what the COM registration process actually involves.

Decision Tree: Which Approach to Use

Work through this in order:

Does the task need to react to model events (save, rebuild, file open, property change)? → Yes: C# COM add-in. Only add-ins can subscribe to ISldWorks event interfaces that persist across operations. → No: Continue.

Does the task need to run on a schedule without human interaction? → Yes: Task Scheduler (if the task is a built-in export type) or Dispatch (if triggered by PDM lifecycle). → No: Continue.

Does the task create new drawings from 3D models? → Yes: VBA macro or C# add-in — Task Scheduler cannot do this. → No: Continue.

Does the task run occasionally, by one person, with no distribution requirement? → Yes: VBA macro. Write it, keep it in a shared folder, run it from Tools → Macros. → No: Evaluate Task Scheduler (export/convert tasks) or C# add-in (anything more complex).

Does multiple people need to run the same logic with zero-touch setup? → Yes: C# COM add-in with an installer. The setup cost is justified by the distribution need. → No: Task Scheduler is usually sufficient.

Where Each Approach Fails

Macros fail when: you need them to run without someone clicking “Run”. They also accumulate technical debt silently — the same macro gets copied across machines, edited locally on each, and diverges within six months.

Task Scheduler fails when: the export task requires any logic beyond “convert all files in this folder to format X”. No conditional logic, no property-based filtering, no per-file naming decisions.

Dispatch fails when: you need to call the SolidWorks API. Dispatch can run a process, but it cannot open a model and interrogate it. For that, you need a separate executable or add-in.

C# add-ins fail when: the setup cost isn’t justified. Building, testing, distributing, and maintaining a COM add-in for a task that one person runs once a quarter is over-engineering. The macro is right for that.

The Hybrid Pattern That Works

Most real automation pipelines combine two approaches:

Task Scheduler + custom executable: Task Scheduler’s “Run Custom Task” action can call a standalone .exe that handles complex logic — property-based filtering, conditional exports, multi-format output. The .exe handles the SolidWorks API calls; Task Scheduler handles scheduling. This avoids building a full COM add-in while still supporting scheduled execution.

Dispatch + external script: Dispatch triggers on a PDM lifecycle event and calls a Python or PowerShell script that handles file management and notifications. For simple release automation (copy to shared folder, send email, increment revision), this covers 80% of use cases without any SolidWorks API code.

Macro → add-in migration: Start with a macro to validate the automation logic. Once it’s proven and more than one person needs it, migrate the same logic to a C# add-in. The API calls are identical — the wrapper changes.

What CadShift Covers (and What It Doesn’t)

If the goal is batch DXF export from SolidWorks assemblies, CadShift handles the automation without requiring any of the above. It runs in-process as an add-in, handles flat pattern extraction from all sheet metal bodies in an assembly, applies bend line trimming and metadata layers, and exports to R2013 DXF — all in one click or as a batch run. It fits the Task Scheduler gap: the export logic that Task Scheduler can’t handle (assembly-level DXF with per-body control) without the C# add-in development cost.

For batch DXF export from a SolidWorks assembly — the common sheet metal fabrication workflow — that’s the direct comparison.

For everything else — custom macros, PDM Dispatch triggers, C# add-in development — you’re building it. The decision tree above tells you which approach to start with.