Inventor/Revit Interoperability Bug

[HogueOne]

TLDR at the bottom.

We are trying to establish an Inventor/Revit interoperability workflow, where Inventor depends on references from a Revit Project. In my research, I've found that Inventor has no issues tracking geometry from system families and Model In-Place components. However, it is unable to track geometry changes from a loaded Revit family. If I use a vertex of a simple adjustable Revit box family as the definition of a work point, and I move/stretch the box in Revit, then update in Inventor, the work point is unable to find the new position of that vertex. I've tried it with all sorts of families, with no difference in result. I've also tried copying the geometry from a Revit family and pasting into a Model In-Place component, and it worked fine. So I can confirm that it's not a problem with the way the family is designed. Inventor just really hates custom Revit families as references. My suspicion is that with system families and model in-place components, the internal IDs of the geometric entities can persist through change; But when a loaded Revit family changes, it seems those IDs are reset and Revit considers it to be entirely new geometry.

What's even more confusing is that if I try to use a Revit family as a reference, and it fails, the document appears to become corrupted. The next time I open the project, I get an error that Inventor is looking for an embedded Revit-imported part, couldn't find it, and is replacing it with another - Except the "other" document that it finds has the exact same file path as the one it says it can't find. If I accept the "change" in resolved reference, and save the file, the error keeps coming back. The only way I could fix it is by writing a custom iLogic script for Deeply rebuilding and updating the active document and all references it finds.

TLDR; In the attached video, the Revit project demonstrates a box on the left that is a Model In-Place component, whereas the box on the right is a Revit family that was loaded. Is it possible to use geometry of imported Revit families as references in Inventor? Can anybody provide proof of this? If so, what could I be doing wrong?

Inventor Build: 233, Release: 2026.1.1 - Date: Wednesday 09/03/2025

Revit Build:

26.0.10.8
20250328_1515(x64)
2026.0.1

[SharkDesign]

Does the same thing happen if you just move and not resize the family?

You are right though, Inventor is tracking the internal IDs, so if Revit changes them, it can't update it anymore and has to create a new one.

I think this is beyond my knowledge, we need @rena_andrews to the rescue.

[HogueOne]

Just moving a Revit family doesn't cause the relationship to break, but I think it corrupts the file anyway. it seems to be resizing a family that causes the broken relationship. Even if the entities were reset though, I expect that it would just break the relationship and not corrupt the file. I can't explain why the file is corrupted by trying to use a family as a reference. Thanks for looking into this.

[rena_andrews · Accepted solution]

Hi @HogueOne, 

Thank you very much for raising this issue! After further investigation and discussion with the team, your suspicion is correct that Interop/update workflows don't work well for the loaded RFAs, particularly for parts (e.g. Simplified or Derived from an assembly), seemingly due to less support for internal ID tracking in Revit compared to Model In-Place component, but I agree it should definitely not be causing file corruption and ideally should also support updates. I was able to reproduce both of these issues. Anyway, because of this, the current best practice/recommendation is to use Model In-Place components for these types of Interop workflows. However, I've created a high priority defect to investigate and fix the file corruption and see if it's possible to also support update workflows (INVGEN-88193). From my testing, it seems to work okay for assembly workflows, but as soon as another layer of abstraction is added with the part workflows it suddenly stops working. I was able to maintain some Inventor features/references if I derived a part from the assembly, then updated the assembly before updating any changes to the part, however I would still not recommend this because as you noted it appears to causes some corruption and becomes very unstable, crashing frequently. But I'm hopeful it means that maybe we can add some support for it so there's more flexibility for these interop workflows. I notice from your video it looks like you derived a sheet metal part from another part containing some surfaces, can you share any other details about how you created this part so I can make sure we investigate and potentially verify any related fixes as well? I noticed it also seemed to be a test on your end, so feel free to share your most common/desired workflows here to make sure we have them all covered. 

Thanks in advance for your help and once again for your report!

Best,

-Rena

[HogueOne]

@rena_andrews

We appreciate you taking the time to investigate this matter, and eagerly anticipate a patch that will hopefully improve support for it. To give you some context, we design and manufacture panel facades for the construction/architecture industry, which is how we've found ourselves necessitating a Revit/Inventor interoperability workflow. Our vision for an ideal workflow is as follows:

1. Receive a Revit model from our client.
2. Create two new 3D view and strip it down to the minimum needed for Inventor reference.
   • One view for export to Inventor
   • One view for import from Inventor
3. Using Revit families, build the grid of precise bounding boxes for our panel facade.
4. Import the appropriate 3D view model of the Revit project into a new assembly document. It's important that we import it as a reference, and not a conversion, since we may need to make changes later than we want to update in Inventor.
5. Derive that assembly into a part document as a surface model.
   • An additional derivation is required if we need to merge faces on the solids, as you cannot merge faces and convert to surface in one operation.
6. Identify bounding boxes that represent identical panels, and prepare sketch driven patterns of work points for later use.
7. Using one of our custom scripts, Copy our product templates (Flat, L-shape, C-shape, etc.) as many times as required for the project. Each of these templates has intelligence built into it, including important BIM information, metadata, CNC toolpaths, and a drawing. Our panel templates contain a placeholder derived part (a simple box) that they reference for size/shape/position.
8. For each copied template, we use the 'Replace Base Component' command for our placeholder derived part, swapping it out for our project specific derived part representing the collection of bounding boxes we've imported from Revit.
9. Using another custom script, we can quickly snap our template to the desired bounding box. We'll repeat this process for each unique panel, and adjust as necessary.
   • Some panels have additional flanges that previously referenced a work point for their definition. The script we wrote temporarily severs the relationship, and uses an algorithm to try to redefine the correct position for the work point. If it fails, the user will have to explicitly redefine the work points and restore the relationship of the flange to the referenced work point. We find that using a work point is more stable than referencing a vertex because if the vertex is lost in translation for some reason, the work point will switch to grounded, stabilizing the flange.
10. Using the sketch driven patterns we created earlier, we can populate all duplicate instances of a panel on a wall.
11. With a completed assembly, we'll export our inventor assembly as a connected Revit project.
12. We'll import this new Revit project into the original Revit project, ensuring that the imported model is visible in the "import-from-inventor" 3D view and not the "export-from-inventor" 3D view, to avoid cyclical dependency or feeding the Inventor model back into itself.
13. Using Revit, we'll detail the imported panel assembly in context of the building and submit for client review. With an approved design, we'll advance to the construction phase.
14. We'll use a scanner to produce a point cloud of the building, and use this data to adjust our bounding boxes of panels in Revit as necessary. If we've set it up correctly, we'll be able to update the Inventor assembly using the potentially new positions of these bounding boxes.
15. From there we will tweak the fabrication details of each unique panel, make a nesting document, and submit for manufacture.

I've attached a video of how the derived Revit project would be used as a reference for these templates. For now, we will use the workaround you suggested. Do you have any idea on what kind of timeframe we could expect this to be addressed in a patch? (E.G. weeks, months, years)

Frequently asked questions:

Why not use the iCopy tool for this type of workflow? 

• Very limited file management and naming support.
• Only works for assemblies, not parts.
• The resulting iCopy becomes a specialized assembly feature in the browser with additional limitations
• Sometimes an opposite solution would be used, causing flanges to invert
• It’s primarily designed to be adaptive only in 2 dimensions. The less you constrain a model, the more prone it is to adapting wrong or causing errors.
• Adaptive assemblies/sketches are delicate. In my experience if you’re not very gentle and precise with the assembly it's adapting to, it will stop working or throw errors.
• Adaptive components are computationally heavy. If you have a hundred adaptive components in a one assembly, any minor adjustment could force a major recalculation. If we run out of ram there’s a chance the software will crash or it will just break the whole arrangement
• While adaptive assembly is a feature of Inventor, it’s not taught as best practice because while it might achieve an iteration of a project faster, manipulating it is a nightmare. It’s what they call ‘lazy’ design.
• We've found that the approach we are now using gives us the most stable results, with greater control, and is much easier on the system to calculate than the iCopy method.

It looks like you're using an iLogic tool as a full-fledged application. Wouldn't an add-in make more sense?

• An add-in does make more sense.
• We've started with iLogic because it is very easy to test without restarting the application.
• In the future we plan to convert our iLogic to add-ins.

[HogueOne]

@rena_andrews 

We attempted your work-around suggestion and didn't see much better results. In the attached video, we have a part document deriving the assembly containing the references from Revit. these are generic models, and not loaded families. I defined work points at the corners of one of the blocks, and defined a plane using those 3 work points, and then offset that plane. In a planar sketch, I used references from the model to draw grid lines and used the mark command to divide the surface into panels. This served as the foundation for applying our panel templates.

As you can see in the video, after a change was necessary and the model updated, everything dependent on the model was destroyed. Since this happened to me before, I decided to sketch on a work plane by points that could be grounded if it happened again, which it did. the only way to prevent destruction through the update is to suppress the link to the derived component, ground the points, unsuppress and update, redefine the points, use the 'Replace Reference' command to reattach every projected edge, and use a custom script to delete any remaining orphaned sketch points, as these cannot be deleted manually. I've attached the Revit document that was given to me that I used to reference in case you wanted to see if the issue could be reproduced.

Do you have any other ideas for getting interoperability to work, or is it just busted?

[rena_andrews]

Thank you very much for the detailed explanation about your ideal workflow for your derived Revit projects, @HogueOne! I'll add these details to the defect so we make sure to cover for example additional levels of derivation, as I suspect there might be update issues with multiple levels of abstraction regardless of the type of RFA used in that case (I was only testing one level before). This is great feedback/insight to share with our designer for future Inventor/Revit Interop considerations in general, so I have also passed it along to them. As you know we can't make any promises or guarantees for a fix version, but I've set it to a high priority, so it's currently targeted for 2027 or 2027.1 (we always try to backport if possible, but whether or not it's feasible requires additional investigation). However it's hard to predict for interop defects, e.g. if we require any fix from the Revit side instead of only Inventor, so that could also affect the fix version.

Also thanks for following up about the workaround, previously I was testing on a newer internal 2026 build when the derived part workflows worked for me, so I rolled back to build 233 to try it again, but I still can't quite reproduce the issue from last video you shared. Here are my steps just in case I'm missing something..

1. Import your 62418 RVT by reference into Inventor 2026 (build 233) - default settings
2. Create a part > Derive (I tried the maintain each solid as a solid body and Single composite options), otherwise default settings > Save the part
3. Added 3 work points and a workplane (identical to yours)
4. Open 62418 in Revit (2026.4), adjusted the length/width of the component I added the Inventor work features to > Save
5. Update the derived part in Inventor

On my end, the workplane doesn't always adjust to the new work point locations after update, but I'm at least not losing them like in your video. Since I'm not sure what version you're using, and if my steps are the same, that makes me wonder if a fix or improvement came from the Revit side. Have you updated to the most recent Revit Interoperability (now 2026.4) under Inventor Professional Extensions in manage? This component handles all of the BIM import/export translations, etc. If not, does this improve the issue at all? I'm also using the latest version of Revit 2026 (2026.4) to modify the RVT by the way. I'm hoping a potential Revit Interop update will fix this issue for you, or if not that we can figure out why I'm not reproducing the same issue on my end so I can also add this requirement to the defect (but hopefully the former!)

[HogueOne]

Thank you for the suggestion. We updated the extension and tried an additional test. The result was strange. When I open the Inventor assembly it claims that the imported Revit component cannot be resolved. But if I save the Revit document, it can detect that it was saved and prompt me to update the assembly. Even after updating, it still believes the file is unresolved. I can't even right click the component to try to resolve it manually. You can observe the test in the attached video.

My conclusion is that the interoperability between these applications isn't mature enough to offer a meaningful solution the way we hoped. We'll find another way to operate without depending on references from Revit. Maybe we'll be able to revisit this when version 2027 releases.