Skip to main content
Autodesk Authorized Developer +91 40-4528 7403 sales@fdestech.com

Platform · SolidWorks API · macros · rule-based design

SolidWorks Automation
for product lines that outgrew macros

Ten configurations, a VBA macro handles. Ten thousand (sizes times materials times options), and the macro becomes the thing everyone works around. We build SolidWorks API add-ins, DriveWorks rules, and PDM automation that treat your configuration logic like the production system it actually is.

Recognized by the vendor itself SolidWorks published a case study on our design automation work

The challenge

The Day the Macro Stopped Scaling

Every SolidWorks shop automates something. The trouble starts when order volume grows faster than the VBA behind it.

The Macro Only One Person Can Run

It breaks on version upgrades, takes no user input, and lives on one machine. When its author is out sick, so is the automation.

Configurations Multiplying

Every new size, material, and option multiplies the matrix. Senior engineers spend their days changing parameters and suppressing features instead of designing.

Design to Manufacturing, Unpiped

Models, drawings, BOMs, and the PDM vault each managed by hand. Nothing moves from order to release unless someone personally pushes it.

Macros vs API vs DriveWorks

The Three Levels of SolidWorks Automation, and When to Move Up

Every SolidWorks automation project sits on one of three levels: recorded and hand-written macros, compiled API add-ins, or rule-based configurators like DriveWorks. Teams get stuck when they ask one level to do the next one's job.

Macros (VBA)SolidWorks API (.NET)DriveWorks / Configurators
What it isRecorded or hand-written VBA running inside SolidWorksCompiled add-ins with Property Manager pages and task panesRule-based design automation driving SolidWorks from a form
Best atSingle repetitive tasks: exports, property fills, one-off fixesDrawing generation, PDM/ERP integration, complex configuration logicSales-facing configuration of a defined product family
Built byPower usersDevelopers who know CADEngineers, with rules discipline, plus API work at the edges
Breaks down whenIt needs a UI, error handling, or another user's machineRarely; this is the production layerLogic exceeds what rules express, at which point it calls the API
Typical projectBatch exports, drawing cleanup, property standardizationOrder-to-CAD pipelines, quotation tools, PDM automationConfigure-to-order product lines, sales self-service

The pattern we see most: a macro that grew into a business-critical system without ever being engineered as one. The fix is rarely a bigger macro; it's moving that logic into a .NET add-in, and putting DriveWorks in front only where sales needs self-service. Our deep dive: SolidWorks automation: macros, API, and rule-based design.

Scope

What SolidWorks Automation Can Take Off Your Team's Plate

Model Generation

Parts, assemblies, and configurations built from order data or design tables: master models that reconfigure instead of getting rebuilt by hand.

Drawing Automation

Views, dimensions, annotations, and title blocks generated from the model in one pass, to your drafting standards, for every variant.

BOMs & Cut Lists

Bills of materials and weldment cut lists extracted straight from assemblies, with custom properties and part numbers applied by rule.

Batch Operations

Exports to STEP, IGES, DXF, and PDF, custom property updates, drawing conversions: all run across entire folders while nobody watches.

PDM & ERP Integration

Files checked in, revisions controlled, and design data flowing to ERP automatically. The vault becomes infrastructure, not ceremony.

Sales-to-CAD Pipelines

Configurators where an order arrives as a form and leaves as validated models, drawings, and BOMs, and engineering only sees the exceptions.

Results

What SolidWorks Teams Measure After Rollout

90%Reduction in configuration time
3xOrder volume capacity
ZeroInvalid configurations
100%BOM accuracy
"Although our project was very open-ended and hit many unforeseen obstacles, Nagarjuna and his team were very adaptable. Their Windows Automation expertise is top-notch." Eli Cohen · Founder · MTailor

Proof

Proof, Including From the Platform Vendor Itself

Published by Dassault Systèmes

When the company that makes SolidWorks writes up your automation work, that's the reference you lead with. SolidWorks published a case study on FDES design automation: vendor-level validation of how we build.

View All Use Cases →

FAQ

Asked on Nearly Every First Call

When should a macro become an API add-in?
Three reliable signs: the macro needs input from users who didn't write it; it breaks on SolidWorks version upgrades and someone has to nurse it back; or it has quietly become business-critical, with orders waiting on it. At that point it deserves software engineering: a compiled .NET add-in with a real interface, validation, and error handling.
Can you rescue our existing VBA macros instead of rewriting everything?
Often, yes. We audit what the macros actually do, stabilize the ones worth keeping, and migrate only the logic that has outgrown VBA into .NET add-ins. A working macro that runs one task reliably doesn't need replacing; the one that runs your order flow does.
DriveWorks or a custom API solution: which one do we need?
DriveWorks wins when the product family is well-defined and the goal is sales self-service on rules engineers can maintain. The API wins when logic is complex, cross-assembly, or needs deep integration with PDM and ERP. Most mature systems we build use both: DriveWorks as the front door, the SolidWorks API doing the heavy lifting behind it.
Can it generate drawings and BOMs, not just models?
Yes; for most manufacturers that's the payoff. The SolidWorks API places views, applies dimensions and annotations, fills title blocks, and extracts BOMs and cut lists with properties set by your rules. Model, drawing, and BOM come from one generation pass, so they can't drift apart.
Does it work with SolidWorks PDM?
Yes. The PDM API automates check-in and check-out, revision control, data card updates, and data extraction, and we integrate vault workflows with ERP so released designs flow downstream without anyone exporting spreadsheets.
How long does a SolidWorks automation project take?
Typically 8–16 weeks to production depending on product complexity and outputs. We build iteratively: working automation on your own products in the first few weeks, not a big reveal at the end. See our pricing guide for typical investment ranges.

Free · no obligation

How Many Configurations Are You Managing by Hand?

If the answer needs a spreadsheet, it's time. The audit maps your variant matrix, your macros, and your PDM flow, then tells you where automation pays back first, in numbers you can take to management.

The workstation configurator that cut turnaround to 30 minutes →

  • Your variant matrix and configuration process, mapped
  • Macros worth rescuing vs replacing, identified
  • DriveWorks and PDM opportunities ranked by ROI