Nested Families – To Share or Not to Share?

Nesting in Revit allows us to place families within other families in order to display their combined geometries and make them behave like a single unit within a project. There are many use cases for nesting content, such as use of repeated components or parametric elements in an array.

There are also situations where placing a set of families together would be very convenient, for example a table and its surrounding chairs. But if we do this by nesting chairs within the table family, we wouldn’t be able to count those chairs independently at a later stage.

This is where shared nested families come in. By making the chairs as shared nested elements, we get the best of both worlds: ease of placement within the project, and full functionality for the information contained within the nested families.

The best way to think about when to use shared nested elements is when those elements could also be used on their own within the project. On the other hand, regular (non-shared) nested families should be used to aid in the creation of repeated elements when creating content.

A good example of when it makes sense to use shared nested families is the one mentioned above: chairs being nested in a table family.

We cannot, however, tag or schedule nested elements in Revit unless we enable the ”Shared” parameter in the nested family before inserting it into the host family. Below is the help text that Revit displays for the “Shared” parameter...but what does that all really mean?

When loaded into a project, a family with shared nested families begins to behave very similarly to a group in Revit. All shared nested families are individually loaded into the model alongside the main host family. So when the host family is placed somewhere in the model, Revit recognizes the instances of its shared nested families as if they were placed individually in the model as well.

When loaded into a project, shared nested families behave like any regular family, but still have the benefit of being placed and grouped within the hosting family. Table and chair can be nested as shared into a new host family, then the model can be quickly populated with such assemblies. Sharing nested families transforms regular nested families from tools that help to build families, into tools that help us build models.

We can select the shared nested elements, tag them and schedule them. The shared nested elements also display in the project browser, while non-shared nested elements don’t appear at all. The shared nested elements can also be edited in the family editor and brought back to the model, updating all instances of the nested element.

Shared nested families have a category that is independent of their host. This category will define how the shared nested families display in views.

All filters and visibility settings that apply to the category of the shared nested families will affect them independently of the host. At the same time, filters and visibility settings applied to the category of the host family won’t affect its shared nested families if they are of a different category. For example, hiding category of Furniture won’t hide shared nested casters of category Generic Models.

Depending on the types of content involved and their use within a project, there will be tradeoffs between the benefits of sharing nested families and the benefits of treating a host family and its nested elements as one single family.

MEP systems offer some more creative options for using shared nested families. But that’s material for another post.

Shared Components in MEP Systems

Now for a little story about working with shared nested families...

While developing the LINK TO FUZE COLLECTION, we wanted to allow for scheduling of the couplings that are required between the pipe and a fitting. One of the ideas we came up with was to make those couplings shared and then nest them in the fitting family. This way, Revit would recognize those couplings individually and they would be picked up in schedules. After all, this is what this option was designed for, right? Well, not quite.

Connected MEP families – such as pipes, fittings, or accessories – can form part of a Piping System such as drainage or domestic water. When the couplings were shared, however, Revit did exactly what it’s supposed to do and treated them separately as Pipe Fitting category families. So while Piping System got assigned to the pipes and their connected fittings, it did not get assigned to the nested couplings – they remained as Pipe Fitting families. In turn, system and filter-based overrides did not apply to them.

In the end, we did not go down the route of shared couplings need to speak with chris what the solution ended up being because it looks like we stuck with shared? . Truthfully the path to this solution was paved with compromises but that deserves a post in of itself.

Naming

Shared really means shared! Within a model, a shared nested family is identical across all families into which it is nested. Loading a family with a shared nested family into a model where another family with the same name (as the nested family) already exists will result in the following dialog.

This is great for maintaining consistency, because it ensures that one and the same version of the nested family is being used across the project. This is a luxury we don’t have with regular nesting, where modifications would have to be done separately in each host family. This feature, however, makes it critical to have a solid naming convention.

Names such as “desk”, “handrail” or “handle” for regular nested families don’t see the light of day when loaded into a project, and different families can have a different nested “desk”, “handrail” or “handle”. This is not the case if the nested families are shared.

A shared nested family that is unique to one particular host family should have a unique name. For example, the name of the host family can be added before the name of the shared nested family. This way, it’s clear that it’s distinct from other such nested families that might get loaded and used with other host families.

If a shared family is not meant to be placed on its own within the model, and will only be loaded as a nested family, then it’s also good practice to indicate this in the name. For example, we can append “-to be nested” to the shared family’s name.

The ability to nest families is a useful tool for building content, but that use is limited to the host family. By sharing nested families, Revit will bring them into the model on their own, which not only allows us to tag and schedule them, but also allows us to ensure consistency across all model families in which they are nested.

This means that standards applicable to model families (such as naming conventions) need to be applied to shared nested families as well. We should be selective about what really needs to be shared and approach this setting with a particular use case in mind. In the majority of cases, it will be best to leave the Shared setting off.

In a follow-up post, we’ll take a look at a few tricks and workarounds that rely on shared nesting – in particular issues with cuttability when using masking regions and detail lines – as well as how to show generic annotations of vertically placed face-based families in plan views.

Even then, there may still be some edge cases as we discussed with pipe fittings above but now hopefully you can identify potential issues before committing to setting the family as shared. In some cases as with the display of generic annotations in nested families sharing the family offers a way to do it.

ers a workaround to a particular limitation and sometimes you’ve gotta do, what you’ve gotta do... Just be careful, Revit is a collaborative platform. 🚧   Naming is crucial both when ... Families that are nested but shared will appear in the project and therefore to other users. Name them accordingly and consistently.

In the follow-up articles we’ll take a look at ... workarounds to Revit’s bugs features, in particular..sectinalbe families..face based

This can come in particularly useful when creating furniture systems, window assemblies or even doors should we want to go as far as scheduling ironmongery.

This article aims to shed light on how Revit works with shared nested families, and how to avoid common pitfalls when using them in projects. Part of this will take a page from our lessons learned during the development of the LINK TO FUZE COLLECTION, where a seemingly nice solution for scheduling would cause issues with visibility. We will also discuss the importance of naming.

We can now TAB-Select those sub-components, tag them, and schedule them. In addition, as a shared sub-component will display on its own in the Revit project browser, if you then edit that sub-component within the model, it will affect the nested family in all other host families that use it - because they all share that same family.

Another thing we will notice about shared nested families is that they retain their Revit family category. This is extremely important, as it directly affects how (and if) elements are displayed.

Say we build a main host family as Furniture Systems and nest within it a desk and a chair – both of category Furniture – and nothing else. If the desk and chair are not shared, then, when loaded into a project, our assembly will behave as a single instance of a Furniture Systems family. To hide it, we can turn off the visibility of Furniture Systems. Meanwhile, changing the visibility of the Furniture category won’t do anything, because Revit doesn’t recognize the nested components as separate Furniture category families.

If, however, the desk and chair families are nested as shared, then they do get recognized separately. In this case, Revit will see the main host family comprised of a desk and a chair – both Furniture category families...and that’s it. Hiding the Furniture Systems category won’t do anything, because the desk and chair are recognized individually as Furniture. On the other hand, hiding Furniture will hide the desk and chair, leaving us scratching our heads as to why our Furniture System family has disappeared.

Shared sub-components shouldn't have a generic name unless they are generic and common across all other families.

When shared, there will be only one family named “desk”, “handrail” or “handle” in the entire project, and that family will be referenced in all families hosting it.

Likewise, if the shared sub-component is specific to a particular family and we want to “un-link” it from the rest, then all we have to do is change its name, for example by adding a prefix with the name of the host family. This way, the name indicates the intention to other users and it gets listed together with its host in the project browser.

On the surface, the original intent of shared nested components is to enable tagging and scheduling in a project. But with a good naming convention and attention to detail, sharing can also be a great tool for ensuring consistency across multiple families using the same sub-components.