Inventor variant management in 2026: iParts, model states, iLogic and Vault compared

In a recent conversation, a machine builder described a familiar situation. The company runs a standard platform in Autodesk Inventor, one base machine with many variants, and most new variants start from an existing component: a designer opens a similar part or assembly, saves a copy and changes what differs. Each copy is quick. Over the years it has become hard to say which copy is current, corrections reach only some of them and the part master keeps growing. This article compares the tools Inventor and Vault offer to manage variants on purpose and shows when a configurator is worth building.

Why copy-and-modify makes variants unmanageable

Copy-and-modify creates a new, independent file for every variant. Inventor then knows no link between the copies, and the knowledge of which dimensions and options belong together lives only in the heads of the designers. Each copy is cheap on the day it is made. The cost shows up later, in maintenance, numbering and every change to the platform.

• Corrections do not propagate. A fix to a bracket reaches the copy that is open, and none of the other copies made from the same original.
• Duplicates pile up. Two designers copy the same part for two orders and create two part numbers for one geometry, each with its own drawing.
• Drawings fall behind. Save As copies the model only, so the drawing has to be copied and re-referenced separately, and that is where wrong views and old title block data slip in.
• Rules fail quietly. iLogic rules that contain file or component names as text no longer find their components once those names change.
• The platform loses its shape. After a few years the copies differ in details nobody decided on, and the standard platform exists mainly on paper.

Designers copy because file copying is the only variant mechanism that needs no preparation, so it wins whenever a deadline is close. The way out is a platform structure in which the right variant is quicker to get than a copy.

The Inventor tools for variants

Autodesk Inventor has three built-in ways to define variants, and Autodesk Vault adds controlled copying and part numbers. The approaches differ in where a variant lives: as its own file generated from a table, as a state inside one file, as the result of rules in a master model or as a managed copy with a new number.

iParts and iAssemblies

An iPart or iAssembly is a factory file with a table. Each row is a member, and each member becomes its own part or assembly file. Columns hold parameters, iProperties, suppressed features or, in an iAssembly, the components to use. An iAssembly can contain iParts and other iAssemblies, which the iAssembly Author handles with Table Replace columns, and the table can be edited in Excel.

Because members are separate files, each one can carry its own part number and be released on its own. Autodesk’s help recommends iParts and iAssemblies exactly for that case, when separate files must be managed and released. One restriction applies in current releases: the iAssembly Author does not create an iAssembly from a model that has more than one model state.

Model states

Model states arrived in Inventor 2022 and replaced Level of Detail representations. When an older assembly is opened, its user-defined LODs and substitutes are converted to model states. A model state stores a variant inside the same part or assembly file, with its own parameters, iProperties and BOM. A drawing view can show any model state, and the first state is always Primary.

Recent releases made model states easier to maintain. Inventor 2026 added a built-in table editor that no longer needs Excel and lets you edit several model states at once. Inventor 2027.1 shows model state previews in the Open and Save As dialogs and asks for generated model states before an assembly is published to Content Center. In Vault, opening an assembly in a chosen model state downloads only the files that state needs.

iLogic configurators

iLogic adds rules to a part or assembly. Rules are written in VB.NET-based code and react to values that designers enter in iLogic forms. For variants, three functions do most of the work: Component.IsActive switches components on or off, Component.Replace swaps a part or subassembly for another file, and Component.ActiveModelState picks the model state of a component. Autodesk calls the approach of modelling all valid options in one assembly and switching between them super modeling.

Inventor 2027 adds Codeblocks, a visual editor that builds iLogic rules from blocks. Copies of a rule-driven template are made with iLogic Design Copy, which copies the files of the project workspace and reuses linked files outside it. When the logic outgrows iLogic, it moves into an add-in; the trade-offs are covered in iLogic vs Inventor API.

Vault Copy Design and items

Vault Copy Design copies an Inventor assembly structure together with its drawings into a new design. For each file you decide whether to copy, reuse, reuse branch, replace, exclude or detach it, and new file names come from a numbering scheme. That turns copying into a controlled step: released platform modules are reused, and only the order-specific files are copied.

Items and BOMs are available only in Vault Professional. An item carries the number, revision and lifecycle state of a part or assembly, and when a part used in several assemblies is released, its new revision appears in the BOM of every assembly that uses it. Read more on Autodesk Vault consulting.

Comparison of the approaches

The right approach depends on three questions: how many variants a module has, whether each variant needs its own released file and part number, and how often the rules change. Most platforms end up with a mix of tables for fixed size steps, rules for dependent options and Vault to control what still gets copied.

Model states and iParts are often presented as rivals. The deciding question is narrower: does each variant need its own released file with its own part number? If it does, use iParts or iAssemblies. If the variants are states of one design that are released together, model states keep everything in one file and spare you the member files.

How to structure a standard platform

A manageable platform separates what never changes, what changes in fixed steps and what follows rules. We recommend sorting every module of the platform into one of these three groups before choosing a tool, because the group decides the tool. Each module then gets one owner who maintains its table or rules.

1. List the modules and their variants. For each module of the base machine, note which options and size steps actually occurred in past orders and which combinations are not allowed.
2. Fix the interfaces. Mounting points, connection dimensions and iMates between modules stay the same across variants, so a module can be swapped without reworking its neighbours.
3. Choose the tool per module. Fixed steps go into iParts, iAssemblies or model states, rule-driven options into iLogic and purchased assemblies into Content Center, which since Inventor 2027 also holds multi-component assemblies such as motors.
4. Release the masters in Vault. Factory files, master models, external rules and templates are checked in and released, and designers place them from Vault instead of from a local copy.
5. Copy only the order level. A new order starts with Vault Copy Design, with released modules set to reuse, so only the order-specific top assembly and its drawings get new numbers.

We hold two positions here. First, a platform module is never copied for a single order: if an order needs a change, the module gets a new row in its table or a new option in its rules, or the order gets a one-off part outside the platform. Second, part numbers belong to the module variant, so the same variant carries the same number in every order. Both keep the platform the single source for every variant, which is also the basis for Inventor iLogic automation later on.

When a configurator pays off

A configurator pays off when a product family recurs often, its rules are stable enough to write down and each order needs a correct model, drawing and BOM quickly. It does not pay off for one-off designs, for families with few variants or for rules that change with every order. You can get there one module at a time.

• The same module is adapted again and again with the same few decisions, such as length, drive side or sensor package.
• The rules can be written as a table or as if-then statements, and an engineer can check them.
• Sales or project engineering waits for the design department to answer feasibility and BOM questions.
• Drawings and BOMs of a variant must be right without manual rework.

We start with the module that is copied most often. An iLogic configurator for that one module, with a form, rules and drawing updates, shows quickly whether the rules hold up. Configured variants still need a check against your design rules, which an Inventor design rule check can run automatically.

A configurator for sales or customers outside the design department needs Inventor running on a server or in the cloud. Autodesk ended new subscriptions for Configurator 360 in 2020 and points to the Design Automation API for Inventor on Autodesk Platform Services, which runs existing iLogic rules and Inventor API code in the cloud.

Wondering whether a configurator pays off for your platform? See how we build CAD configurators for Inventor together with your design team, starting with one product family.

Limits and pitfalls

Every variant mechanism in Inventor moves work from the copy to the definition. Tables, model states and rules need an owner, a test run after each Inventor release and clean names. Without that upkeep they decay into the same untraceable state that copy-and-modify produces, only inside fewer files.

• Component names: iLogic finds components by their browser names. Autodesk recommends giving components stable custom names before rules use them, otherwise Component.Replace renames the component and the rule cannot find it on the next run.
• Migrated Level of Detail states keep a delegated BOM that cannot be edited. Autodesk’s advice is to copy such a model state and edit the copy.
• Without Vault Professional there are no items, so part numbers live only in iProperties and file names.
• Strength, safety and approval stay with the engineer. A configurator produces a consistent variant; whether that variant is fit for use is still an engineering decision.

Frequently asked questions