What Is iLogic?

iLogic is Inventor's built-in rule engine for automating parametric design. It uses a simplified VB.NET syntax and provides a library of pre-built snippets that let you control Inventor models without writing traditional application code.

With iLogic, you write rules that:

  • Drive parameter values based on user selections (e.g., if Flange_Type = "Slip-On", set Bolt_Count = 4)
  • Suppress or unsuppress components in assemblies
  • Change materials, colors, and appearances
  • Control iPart/iAssembly member selection
  • Generate iProperties (part number, description, mass) automatically
  • Trigger other rules in sequence
  • Present simple input forms to users

Rules are stored inside the Inventor document (the .ipt or .iam file). When someone opens the document, the rules travel with it. There's no separate installation, no DLL to deploy, no setup required.

iLogic's origin: iLogic was introduced in Inventor 2010 (originally as an add-in, later built into the core product). It was designed as a "no-code" automation layer for engineers — people who understand parametric design but aren't software developers. The syntax is VB.NET, but the pre-built snippet library means you can accomplish a lot without understanding the language deeply.

What Is the Inventor API?

The Inventor API is the full programmatic interface to Autodesk Inventor. It's a COM-based API that exposes every object in Inventor — documents, features, sketches, constraints, drawing views, title blocks, BOMs, annotations, and the application itself. You access it through .NET languages (C#, VB.NET) or, in some cases, through COM interop from other languages.

With the Inventor API, you can:

  • Create custom ribbon tabs, panels, and buttons with professional UI
  • Build dialog boxes, task panes, and property managers
  • Access and modify any entity in any document — parts, assemblies, drawings
  • Read from and write to databases, ERP/PLM systems, and web services
  • Automate drawing creation with views, dimensions, annotations, and title blocks
  • Manipulate the BOM structure programmatically
  • Handle application events (document open, save, close, print)
  • Create entirely new features, sketch geometry, and constraints from code

Inventor API add-ins are compiled into .dll files and deployed via .addin manifest files. They run as external assemblies loaded by Inventor at startup. This is proper software development — version control, unit testing, CI/CD, the full lifecycle.

~3,000

The Inventor API exposes roughly 3,000 classes and interfaces. iLogic gives you access to a curated subset through its snippet library. The API is the full toolkit; iLogic is the quick-access drawer.

Side-by-Side Comparison

Here's how the two approaches compare across the dimensions that matter most in production environments:

Language and syntax: iLogic uses simplified VB.NET with pre-built snippets and auto-complete. The Inventor API uses full C# or VB.NET with the complete .NET framework available. If your team writes C# daily, iLogic's VB.NET syntax may feel awkward. If your team isn't developers, iLogic's snippet library is far more approachable.

Where code lives: iLogic rules are embedded inside Inventor documents (.ipt, .iam, .idw). API add-ins are external DLL files deployed to Inventor's add-in directory. This is one of the most important differences — iLogic rules travel with the file, but they're also invisible to version control systems like Git.

User interface: iLogic offers basic input forms — multi-value lists, text inputs, and message boxes. The Inventor API lets you build full WPF/WinForms dialogs, custom ribbon tabs, task panes, and context menus. If you need anything beyond a dropdown list, you need the API.

Error handling: iLogic rules have minimal error handling. If something fails, you get a generic error dialog. The Inventor API supports try/catch blocks, logging, structured error recovery, and custom error messages — essential for production tools used by a team.

Debugging: iLogic has a basic built-in editor with limited debugging (MessageBox-based). The Inventor API uses Visual Studio with full breakpoint debugging, watch windows, call stacks, and step-through execution. The debugging experience alone justifies the API for complex logic.

External integration: iLogic can read Excel files and do basic file operations. The Inventor API can connect to databases (SQL Server, Oracle), REST APIs, ERP/PLM systems, email servers, and any .NET-compatible service. If your automation needs to talk to systems outside Inventor, you need the API.

Deployment: iLogic rules deploy automatically — they're in the document. API add-ins require an installer (MSI) or manual file copy, plus an .addin manifest. For a single engineer, iLogic wins. For a team of 50, a managed installer is actually an advantage.

80/20

iLogic handles roughly 80% of parameter-driven automation tasks. But the remaining 20% — custom UI, external integration, drawing automation, error handling — requires the Inventor API. Most teams eventually need both.

When to Use iLogic

iLogic is the right choice when:

  • You're automating parametric configurations. Driving parameters, switching iPart rows, suppressing components based on selections — this is iLogic's core strength. If your automation is "when X changes, update Y," iLogic is faster to write and easier to maintain.
  • The logic is specific to one product family. iLogic rules that live inside a template assembly are perfectly scoped. When you open that assembly, the rules are there. No installation needed.
  • Your team isn't developers. Mechanical engineers can learn iLogic in days. The snippet library handles most of the syntax. If requiring Visual Studio and C# knowledge would bottleneck adoption, iLogic removes that barrier.
  • You need rapid prototyping. Testing an automation concept? iLogic lets you go from idea to working prototype in hours, not days. You can always refactor to the API later if the concept proves valuable.
  • You're building for APS Design Automation. Autodesk's cloud automation engine natively executes iLogic rules. If you're planning a web-based configurator, iLogic rules become your cloud execution layer.

Typical iLogic use cases:

  • Product configurators that switch sizes, materials, and options
  • Automatic BOM property population (part numbers, descriptions)
  • Assembly configuration management (suppress/unsuppress based on options)
  • Parameter cascading (change one master dimension, all related dimensions update)
  • Material and appearance assignment rules

When to Use the Inventor API

The Inventor API is necessary when:

  • You need custom UI beyond basic forms. If users need a proper dialog with tabs, validation, search, or preview, you need WPF/WinForms through the API. iLogic's form capability is limited to simple dropdowns and text fields.
  • You're integrating with external systems. Pulling data from SAP, pushing BOMs to your PLM, querying a materials database, calling a REST API — any external system integration requires the Inventor API.
  • You're automating drawing creation. Programmatically creating drawing views, placing dimensions, adding annotations, and populating title blocks is Inventor API territory. iLogic has limited drawing automation capability.
  • You need proper error handling and logging. Production tools that 50+ engineers use daily need graceful error recovery, structured logging, and meaningful error messages. iLogic's error handling is too basic for this.
  • You're building tools for a team. When multiple developers maintain automation code, you need version control, code review, and proper deployment. API add-ins live in Git repositories. iLogic rules live inside Inventor files.
  • You need to handle application events. Reacting to document open/save/close, intercepting file operations, or adding pre-save validation requires the API's event model.
  • You're doing file management or batch operations. Opening, modifying, and saving multiple files programmatically is Inventor API work.

Typical API use cases:

  • Custom ribbon tools for company-specific workflows
  • Automated drawing generation from 3D models
  • BOM export to ERP/PLM systems
  • Batch file processing and migration
  • Design validation and compliance checking tools
  • Custom property managers and data entry forms
The version control problem: iLogic rules stored inside Inventor documents cannot be tracked by Git or any version control system. When two engineers modify the same rule in the same template, there's no merge — one overwrites the other. For teams larger than 2-3 people, this becomes a serious maintenance risk. The Inventor API solves this because the code lives in external files that Git tracks naturally.

The Best of Both Worlds: Combining iLogic and the API

The most effective production systems don't choose one or the other — they combine both. This is the pattern used by the majority of professional Inventor automation tools we build:

Pattern: .NET add-in orchestrates iLogic rules

  • The .NET add-in provides the user interface (ribbon buttons, dialogs, forms), handles external system integration (database queries, ERP calls), manages file operations, and implements error handling and logging.
  • The iLogic rules handle the parametric logic inside the model — driving dimensions, suppressing components, selecting iPart rows, and assigning materials. This is what iLogic does best.
  • The add-in triggers iLogic rules programmatically using the iLogicAutomation interface, passing parameters and reading results.

This separation of concerns plays to each tool's strength:

  • iLogic handles what it's designed for: parametric configuration inside the model
  • The API handles everything else: UI, integration, file management, error handling
  • The parametric logic (iLogic) can be updated by mechanical engineers without touching the .NET code
  • The application logic (.NET) is version-controlled, tested, and deployed independently
Think of it this way: iLogic is the parametric brain inside your Inventor model. The Inventor API is the nervous system that connects that brain to the rest of your organization — databases, ERP, drawing automation, and user interfaces. The best systems use both.
90%

Of the product configurators we build for manufacturing clients use this combined pattern: a .NET application or web front-end that orchestrates iLogic rules for the parametric heavy lifting. It's the pattern that scales.

iLogic and Cloud Automation (APS)

Here's where iLogic becomes strategically important: Autodesk Platform Services (APS) Design Automation API natively executes iLogic rules in the cloud.

This means iLogic rules you write for desktop automation can become the execution engine for web-based product configurators. The architecture looks like this:

  • A customer selects product options in a web browser
  • Those selections are sent to the APS Design Automation API
  • APS runs Inventor in the cloud and executes your iLogic rules with the selected parameters
  • The output — updated 3D model, 2D drawings, BOM, PDF — is returned to the web application
  • The customer sees their configured product and downloads production-ready outputs

This is significant because it means investing in iLogic rules today creates reusable assets for cloud automation tomorrow. Your desktop configuration rules become the backend of your web configurator without rewriting the parametric logic.

The .NET add-in layer is different in the cloud — instead of a desktop application, it's a web service (often called an "AppBundle" in APS terminology). But the iLogic rules that drive the model? They're the same ones running on the desktop.

APS + iLogic compatibility: Not all iLogic features work in the cloud. Rules that reference UI elements (forms, message boxes) or desktop-specific features won't execute in APS. Rules that drive parameters, suppress components, and manage configurations work seamlessly. Design your iLogic rules with cloud portability in mind from the start.

The Typical Migration Path

Most teams follow a predictable progression:

Stage 1 — iLogic rules in individual files. An engineer writes rules to automate a specific product family. Rules live inside the template file. Works great for one person, one product.

Stage 2 — External iLogic rules. As rules grow complex, they're moved to external .vb files (still executed by iLogic, but stored outside the document). This adds some version control capability but still uses iLogic's execution model.

Stage 3 — .NET add-in with iLogic orchestration. The team builds a proper application shell (.NET add-in) that provides UI and integration, while iLogic rules continue handling the parametric logic. This is the "best of both worlds" pattern.

Stage 4 — Cloud deployment via APS. The iLogic rules are packaged into an APS AppBundle. A web application replaces the desktop add-in as the front end. Customers self-configure through a browser.

Not every team reaches Stage 4 — many operate effectively at Stage 2 or 3 for years. But understanding the migration path helps you make investment decisions now that don't create roadblocks later.

Decision Framework

Use this quick checklist to determine your approach:

Start with iLogic if:

  • Your automation is primarily parameter-driven (dimensions, configurations, materials)
  • You're automating a single product family or template
  • You need fast prototyping — days, not weeks
  • Your team consists of engineers, not developers
  • You're planning to move to APS cloud automation eventually

Start with the Inventor API if:

  • You need custom user interfaces (dialogs, ribbon tools, property panels)
  • You're integrating with ERP, PLM, databases, or web services
  • You need automated drawing generation from 3D models
  • Multiple developers will maintain the code
  • You need proper error handling, logging, and deployment management

Combine both if:

  • You're building a product configurator (UI + parametric logic)
  • You need external integration AND parametric automation
  • You want engineers to maintain configuration rules while developers maintain the application
  • You're planning a phased roadmap from desktop to cloud (APS)

The wrong approach isn't choosing iLogic or the API — it's treating the decision as permanent. The best Inventor automation strategies use each tool where it's strongest, and evolve the architecture as needs grow.

If you're evaluating which approach fits your specific products and workflows, we can help you map the right architecture. We've built hundreds of Inventor automation systems across both approaches — and most of them use the combined pattern.