topic Re: Best Practice for Primary Model State/Position Representations? in Inventor Forum

Best Practice for Primary Model State/Position Representations?

mgaunt3DSG — Fri, 30 Jan 2026 12:24:12 GMT

When using Model States and Positions I often find myself annoyed that I cannot give the [Primary] Representation a name that communicates its intended purpose. This has led me to use a couple of different work arounds, neither of which I am particularly happy with:

Make the [Primary] Representation a dummy state that is not intended to be used.
Leave it to the user to deduce what the [Primary] Representation is relative to the others in the list.

I have also found an instance that I would like to Exclude some Positions from an iAssembly that I have been upgrading, but I cannot Exclude the [Primary] Position. I have considered a few work arounds similar to the above to this as well:

Make the [Primary] Position a dummy, I can make the other Positions override a constraint value to make this obvious.
Just leave it to the user to understand that they should not use that the [Primary] Position in those particular iAssembly Members that I would Exclude if I were able to.
Abandon the use of Position Representations and build them into the iAssembly Factory, adding many, many, many rows to the Table.

What methods do you guys find the most success with? Am I missing one?

Re: Best Practice for Primary Model State/Position Representations?

hollypapp65 — Fri, 30 Jan 2026 14:47:31 GMT

I just ignore them. I don't use them.

I add "Default" "Design" to View Rep in Template and Active Default. No more assembly with all planes, axis showing.

I'll use PosRep. It's good for overlay in drawing to show different pos in same view and it reduce Modelstate for each Pos.

Similar with ViewRep. I don't have Black and White ModelState. I have Black and White ViewRep.

Also ViewRep with plane, axis, point, sketch visible when I need them for constrain.

Re: Best Practice for Primary Model State/Position Representations?

swalton — Fri, 30 Jan 2026 19:36:25 GMT

Our workflow:

Model States: Used to simplify or show a concept during the engineering design process. The Primary model state is the only one that will be manufactured.

Position Reps: Primary shows the component at rest. How one might find it in the warehouse or in the showroom. The other position reps show motion, special configurations or other design intent.

Design View Reps:

Primary-a source of frustration and mistakes.
Default - normal working view during design
Painted - Shows the paint/finish
Drafting Annotation - Used for drawing views
Various special purpose views - Named and used for other reasons.

Re: Best Practice for Primary Model State/Position Representations?

johnsonshiue — Sat, 31 Jan 2026 00:04:14 GMT

Hi! I personally would use Primary Model State as the baseline state, meaning all components are unsuppressed and the parameters/properties are the initial values. There is no technical advantage using this approach, however. It just offers a good reference when you try to compare two different Model States.

Many thanks!

Re: Best Practice for Primary Model State/Position Representations?

mgaunt3DSG — Wed, 04 Feb 2026 20:51:22 GMT

Thanks for the replies, guys.

I haven't had a need for View Representations in my Common Assemblies, but I have found them useful in more bespoke assemblies because I can export them in 3D PDFs.

I try to use Model States where I can because I like the Select -> Right Click -> Representation -> Model State workflow over what's available for iParts/iAssemblies. I only move over to iParts/iAssemblies when I have a large number of Configurations and using Keys is helpful. If one or neither of those are true, I am faced with the dilemma I mentioned in the original post, and it seems that there is no one "correct" answer.

In Positions, I haven't been using them for very long outside of Clamps, where I use Primary as a closed by default flexible Representation and have additional Open and Closed Positions which I have found works well. I am trying to improve some of the Common Assemblies that had their positions in the iAssembly Table, and have found a great deal of success so far. For the particular instance I mentioned in the original post I have made the [Primary] Position a dummy, which I find quite ugly and inelegant but better than the alternatives I mentioned. I know file size isn't the most important thing, but I was shocked when the file size of that Component was cut to an eighth of what it was before using the Positional Representation.

@swalton I like the component at rest idea, but what do you do when a model doesn't have a resting position or where many positions are equally valid?

Re: Best Practice for Primary Model State/Position Representations?

lauri_barnhart — Mon, 09 Feb 2026 14:29:30 GMT

Hello, @mgaunt3DSG,

Just checking in—did the responses shared by @hollypapp65, @swalton or @johnsonshiue help clarify your question?

If so, please consider clicking the "Accept Solution" button on the post(s) that solved your problem. Doing so helps others in the community easily find useful answers.

If your question still needs more attention, feel free to reply here with an update. This way, other members can jump in with further suggestions or guidance to help you move forward.

All the best,

Lauri | Community Manager

Re: Best Practice for Primary Model State/Position Representations?

swalton — Mon, 09 Feb 2026 14:59:58 GMT

@mgaunt3DSG wrote:

Thanks for the replies, guys.

@swalton I like the component at rest idea, but what do you do when a model doesn't have a resting position or where many positions are equally valid?

I usually pick one position or configuration to begin the design process. I try to choose based on the most common SKU, or other business logic consideration. It is always possible to redefine the constraints, model states or other configuration settings during the design process if the initial assumptions are not useful.

I also tend to do clean-sheet designs with several different concept development models that explore the solution space before I start the production intent model. The manufacturing, marketing, internal and external user reviews influence these model structure choices.