topic Re: vault does not generate different item for different model states in Vault Forum

vault does not generate different item for different model states

cavallerin — Wed, 14 May 2025 14:58:43 GMT

Hi,
I have an assembly with several model states.
For each model state, I set different part number.
When I come back to vault and I run assign/update item command, it does not create new item for each model state.
What am I missing?
Thx

Re: vault does not generate different item for different model states

ihayesjr — Thu, 15 May 2025 14:00:57 GMT

What property are you mapping to the Item Number?

Check the mapping of the Number system property.

Re: vault does not generate different item for different model states

cavallerin — Mon, 19 May 2025 05:27:15 GMT

This is the mapping and I think that's a correct

.
I think the problem it's related to the file itself.

As I saved it as a new file the items have been properly generated for each model state.

Thanks again for you support.

Regards.

Re: vault does not generate different item for different model states

dpeters1 — Tue, 30 Sep 2025 18:30:53 GMT

Hello, I do not accept this as a solution.

When a file with multiple model states that do not yet have unique part numbers is assigned an item, the item is assigned to the file only. If the model states are then assigned unique part numbers and the file is saved and checked in, assign/update item DOES NOT create new items for the model states with new part numbers.

Deleting the item and re-creating it is the only way I have found to get items assigned to all model states. This is fine unless the item history or other links must be maintained.

Saving the file as a new one and creating an item from that will "work" but in that case the original file AND original item will need to be deleted, assuming one has a clean vault, and item history retention is not required. I believe I also read that creating new duplicate model states and assigning part numbers to them will work, after which you would want to delete your original model states.

I understand that model states are relatively new, and I think they are a wonderful addition to the capabilities of Inventor. I use them frequently. However I think the inability for assign/update item to recognize existing model states with newly assigned part numbers is an oversight on the part of Vault Pro that should be addressed.

Am I missing something? Is there a property mapping conflict causing this? I have "Part Number" mapped both ways between file and vault properties.

Re: vault does not generate different item for different model states

dpeters1 — Tue, 30 Sep 2025 18:36:31 GMT

Re: vault does not generate different item for different model states

ihayesjr — Tue, 30 Sep 2025 19:10:43 GMT

You are not missing anything.

Since you initially associated that model state with the first item, it remains associated with that item even after you have changed the part number.

Re: vault does not generate different item for different model states

ihayesjr — Tue, 30 Sep 2025 19:14:16 GMT

To change it, in Inventor, duplicate the model state and give it the new part number.

Delete the original model state, check it in and assign\update item.

Re: vault does not generate different item for different model states

dpeters1 — Tue, 30 Sep 2025 19:53:19 GMT

Thanks. Yes, I am familiar with the workarounds. My point is that this is a functionality that should be fixed.

Re: vault does not generate different item for different model states

cavallerin — Wed, 01 Oct 2025 05:38:59 GMT

I do agree with @dpeters1 ; Autodesk should make a complete revision to its products functionalities to relief users of tedious work they don't need to.

Re: vault does not generate different item for different model states

ihayesjr — Wed, 01 Oct 2025 12:30:12 GMT

Ok, let's say we add this capability. What should happen in this scenario?

The user creates a model with model states that have the same part number.

The model is checked into Vault and assigned to a single Item since they share the same part number.

The user checks out the model and changes the part number of one model state.

The model is checked in, and an update Item is performed. The model state with the different part number is assigned to a new Item.

The user checks out the model and determines that the part number should not have changed, so they reset the model state to retain the original part number.

What should happen?

Re: vault does not generate different item for different model states

dpeters1 — Wed, 01 Oct 2025 12:43:41 GMT

In that case, which I think is a very rare scenario, I would simply delete the now un-linked item.

Re: vault does not generate different item for different model states

cavallerin — Wed, 01 Oct 2025 12:47:05 GMT

In this scenario, what does not change is the name of the file, which, even though it has different part numbers for the various model states, its reference in the master table (file) does not change.

I also believe that a many-to-many table in the database that links the names of the items to the model states of the file already exists; otherwise, you would need to explain to me how it is possible to select a specific item among those connected to a single model state (a functionality that exists) within the file (see image).

Therefore, I think that implementing a link for active state and inactive state could be a way to manage these reference name changes.

Re: vault does not generate different item for different model states

cavallerin — Wed, 01 Oct 2025 12:55:17 GMT

In any case, I think my issue is relaeatd more to a bug than a feature, but I can't be sure about that.
What I can say is that the deletion and recreation of the file (save as new) only perfoms the writes new "rows" in some tables in the db.

So if this works with a brand new file, why won't this work with already existing file, this is what I can't understand yet...

Re: vault does not generate different item for different model states

ihayesjr — Wed, 01 Oct 2025 14:38:46 GMT

@dpeters1

We can't simply delete the unlinked Item in that scenario. It could be a child of a different Item, or it could have been released at some point.

It may not be as "rare" as it appears to be right now.

@cavallerin

Those new rows in the database are not already associated with an Item. That is why the duplication of the model state and the creation of new files work.

The existing file, and its model states, is already associated with an Item(s). They need to maintain those associations for future updates. (I am going light on the explanation)

Thank you for the conversation. Please create an Idea post for this request.

Re: vault does not generate different item for different model states

michele_cavallerinTTNQ9 — Wed, 01 Oct 2025 15:04:40 GMT

thx for the explanation.

https://forums.autodesk.com/t5/vault-ideas/editing-partnumber-in-model-states-after-items-are-already/idi-p/13833044

Re: vault does not generate different item for different model states

dpeters1 — Wed, 01 Oct 2025 17:37:38 GMT

Thank you @michele_cavallerinTTNQ9 for creating the Idea post, and thanks all for the productive discussion.

One final point is that replacing/duplicating model states, in order to have new ones to assign part numbers to, then deleting the original model states, will break any IDW views associated with the original model states. So it's an undesirable workaround at that.

And what happens now if I delete a model state that has a part number and existing item? What happens to that item?

Re: vault does not generate different item for different model states

dpeters1 — Wed, 01 Oct 2025 20:24:44 GMT

I tried making an assembly with three part-numbered model states, assigned items to them, and then deleted one of the model states. Updated the item for the deleted model state, and it became empty - no longer had a link to the file. Was then able to obsolete/delete this item.

Re: vault does not generate different item for different model states

cavallerin — Thu, 02 Oct 2025 05:56:44 GMT

I think now we come to end this thread as by users we can't define the proper deveolpement of a closed-source software, you know : "My rules are your rules."
Regards.