Model objects in Revit are identified by a unique Type Mark parameter, which Revit makes available only after a family is actually loaded in a project file. As of late, this has become a bit of a stickler.
There are two schools of thought when it comes to templates: the “load it up baby!” group and the “minimalists”. I’m more of the former, but I guess it’s mostly due to some productivity shortcomings in Revit. Now that we actually have a solution in place (Family Browser), I’m officially in the new, middle-of-the-road camp: Load it up, but keep loadable families in your office library only (mostly).
If you load up your template with a ton of families and types, you make it next to impossible (or a big time waster) to use the Insert Component tool coupled with the Type Selector. Unless you have developed a rigid naming system to flock families of a feather to stay together (ex: prefixing with “pfix” for plumbing fixtures, etc.), then there’s a good chance that you have total mayhem in the Type Selector. At which point it makes more sense to simply drag the family type from the Families node of the Project Browser into your canvas. However with Family Browser, you have a more efficient method of loading what you want, when you want it, so that is now my preferred choice.
Unfortunately, on-demand loading presents us with a problem. Until recently, we edited the Type Marks in advance in our template to suit our needs and made sure all details, notes etc. were coordinated with that value. But with on-demand loading, your type mark is populated after loading into a project, resulting in “loss of information/intelligence” as the user has to manually fix type marks in every loaded family. And as Aaron states in his great post about templates, why let your users do something on every project when you can do it once in the template?
This has led us to discontinue the use of Type Marks in our families in favor of our own “Master Type Mark” shared parameter added to each family. I totally understand why Revit adds a Type Mark to a family once loaded into a project, but at the same time there’s no arguing that the current behavior is problematic. Why not let us fill out the Type Mark in advance and just warn us about a conflict once loaded into a project? This would be a much better workflow than forcing us to create redundant shared parameters.