A Short Story About How Nested Families Work When Exported to Ifc.

How to guides By Jul 09, 2026 No Comments

I had a question come through that’ll sound familiar if you’ve ever pushed Revit → IFC on a live job:

Nested families are carrying asset data in Revit, but that data disappears in the IFC. LOI attributes, classification, IDs.. gone. What’s going on?

This comes up more than it should, and when providing advice, far too many people are confidently wrong about it.

At that point people start trying workarounds. Copy parameters up to the host, hardcode values, flatten things out, attempt to modify the IFC post export. It “works”, but introduces another problem. Nice version = You lose uniqueness. Not so nice version = You’re doing it wrong.


The root issue isn’t IFC. It’s how Revit treats nested families and exporting them to IFC.

If a nested family is not shared, Revit doesn’t treat it as its own element. It’s just part of the host. When you export to IFC, the exporter follows that same logic:

  • The geometry comes through
  • The nested family does not exist as an object
  • Its parameters don’t exist either
  • Everything is attributed to the host family

So when people say “IFC dropped my data”, it usually didn’t. The element never existed as it’s own entity in the export to begin with.

You can see it clearly in a simple test:

  • Host family (cube)
  • Shared nested family (hexagon)
  • Non-shared nested family (sphere)

Export that and open it in an IFC viewer.

The shared element shows up as its own object. It has its own GUID, its own type, its own parameter set. Everything you expect.

The non-shared one? It’s just geometry baked into the host. No identity, no properties, no trace of the original family.


The fix is straightforward:

Open the nested family → go to Family Category and Parameters → tick Shared.

Reload it back into the host, then into the project.

That’s all there is to it.

There’s a help article on the Autodesk site that says the same thing, and another one in the Revit Ifc online manual, but it tends to get missed because people assume the issue sits in IFC settings rather than family structure.

There are trade-offs (although I don’t consider them to be).

Making families shared means:

  • They schedule independently
  • They tag independently
  • They show up as separate elements everywhere

That’s exactly what you want for asset components. It’s not what you want for every bit of nested geometry.

So this isn’t “make everything shared”. It’s:

If it needs to exist as an individual asset in IFC (or anywhere else), it needs to exist as an element in Revit.

Simple rule. Easy to check.

One caveat worth mentioning. Not every missing parameter problem is caused by nested families being non-shared.

While putting this example together, I looked at another model where the nested families were already configured as Shared, but all of the data had been assigned to the host family instead. The host family itself contained no exportable geometry, and the model author had applied the data to the host, expecting the host-level properties to automatically appear on the nested families when exported to IFC.

At first glance this looked like the same issue, but it was actually a different modelling problem.

The important distinction is that IFC is not “pushing” data between families or allowing nested components to overwrite host properties. Revit only “pushes” data between host and nest if you configure parameter linking within the family. Shared and non-shared families determine how elements are represented in the export. Where the data is stored then determines which IFC element receives that data. If you want the data to appear on the nested shared family, you need to apply the data to the nested shared family.


But don’t just take my word for it.. Check it out yourself and inspect the files. I put together a small demo model and IFC export here: View the GitHub repo

It shows both cases side by side so you can see exactly what changes. The Revit file is 2025 format, so you’ll need 2025 or newer to open it up.

A lot of IFC issues aren’t export problems. They’re often modelling decisions made in an attempt to save time that don’t surface as problems until you’re scrambling to get your deliverables out the door.

No Comments

Leave a comment

Your email address will not be published. Required fields are marked *