At present it's not a problem for me to manage since I'm the only one who makes our content! That said, when my predecessor was here, we were very much in opposition to family modelling. Their argument was always "LOD" & file size - mine was construction accuracy.

Taking doors as an example, yes, we can get away with simple geometric abstractions of a door and use parameters to define their other qualities (ironmongery, frame type, lintel, sill, etc) - but later down the line, in fine view, at scales approaching 1:50, 1:20, those families start to find their shortcomings both visually and operationally - and so I advocate a finer grain of modelling - but still limit that to what I see as essential for understanding each door - which, I'm afraid to say, varies from job to job, and door to door.

Another argument for detailed families I'm fond of is in their design documentation - we can take a door in isolation and detail it up for manufacture when it's a close approximation to the built thing - whereas a "panel+swing" generic family tends to require additional detailing work in addition to dimensioning and annotation, or the use of nested detail families, which just seems a bit a "meh" in terms of productivity gain.

I'm actually looking at my/our approach to doors again, returning once more to assembles built on nested shared families. I know the arguments against, but there's something satisfying about "building" a door from parts (see attached screenshots from my study) - even if that does mean having to have libraries of openings, frames, panels, etc... but the flexibility within this option and the possibilities of VG and scale-based control of appearance, all keep clawing me back to it. I just know it'll be difficult to win over my lot at work.

Ive never heard an argument AGAINST nested shared families for doors, that i thought was a "good" argument. Ever.

If you build a good enough *kit of parts* and *kit of family templates* your office staff can put as much detail in a door as they want, and they can do it quickly.

Amen for your thoughts snowyweston.
I have also been struggling with nested components.
My first case was when I had to do a door with frame and panel from different manufacturers.
Keeping all in the same family was absurd because it would duplicate some parameters.
I still haven´t found a clear defined workflow, and have been working on a solution based on the supercomponent parameter.
My problem is creating a clear schedule inside revit to show up the relationship between the nested and the parent instances.

For scheduling I'm currently liking two yes/no shared parameters "Assembly" and "Component" linked by an =OR statement, in each family, that I can filter by. (the fields are hidden in the above screenshots) I just wish you could do format family type fields so they only report the type.

And you will see I use a "A_" and "C_" prefix to their family names for organising them in a browser. Not worked out how I'd like to do the type names of assemblies just yet.

I have found that is really depends on the firm and how in depth you go with regards to your detailing. I know companies that would rather create completed families for a manufacturer instead of a door with different types inside it. You could also argue that you need to model the detail 100% vs creating a 3D Square shape and having detailing done for the visibility settings.

Once you have a better understanding of you want for your company it is easier to make the families and therefore less wastage on time. If you know your companies current work process of documenting your components and a good understanding of family creation it will be easy to decide how you want to manage your families.

How would you guys deal with more that one level of nesting?

In what way? As in the handle.rfa nested into panel.rfa first? Personally, I wouldn't, I can't see what gain there would be.

I like to think of a door as being a sum of all parts - and although shortening addition works in maths, it'll only ever be a bind in Revit (as in, you'll want to get at that nested family at some point, why "file" it deeper?)

I agree with elmo on this and with you bjohn. We are a small firm with 3 draftsman, 3 project architects/owners. All of the work we do is commercial which means only a handfull of different types of doors and such. Also the work we do is mostly on a bid type basis which means multiple manufacturers for each object required by law. To us the generic types you called out seem to work for us. Utilizing the types for your doors and adding details to your "opening/door elevations" could be the fine tuning of special conditions. I don't want to nor do I have the time to model all of these components and have a door with a single piano,two,three or four hinges, closures, levers, panic devices and so fourth. Make the contractors read the specifications for what you want. Time is money.( This is my opinion only and this statement was in no way directed at anyone or to cast judgement upon anyone.)................which ever works for you.

Well, I use this for frames... I've created separate families for frame types, nested those in a frame family, which comes into the door/window family.
Also: Detail Component families in the Frame Family which comes into the door/window family.

But I second the question: in what way do you mean "deal with those"