View Template Inheritance: Hierarchical Parent/Child Relationships

[s1.young]

The Concept: Introduce a "Based on" or "Parent Template" logic to View Templates, similar to how Paragraph Styles function in InDesign or Word. This would allow a "Parent" template to define global standards (like Detail Level or Model Displays), while "Child" templates inherit those settings and only override specific parameters (like V/G Overrides for a specific discipline).

The Workflow:

1. Inheritance Toggle: Each parameter within a View Template would have an "Inherit from Parent" checkbox.

2. Global Updates: Changing the Font or Scale in a "Parent" template would instantly push that update to 50 "Child" templates, provided those children haven't explicitly overridden that specific parameter.

3. Visual Cues: Parameters that are being overridden at the child level should be highlighted (e.g., bold text or a blue icon) to show they no longer follow the parent.

Why it’s needed: Currently, managing View Templates in large projects is a manual, error-prone process. If a firm decides to change the "Phase Filter" across all 20 of their Plan View templates, a BIM Manager must manually open every single template. Hierarchical templates would reduce maintenance time by 90% and ensure project-wide graphic consistency.

[Ric_Weber]

@s1.young The way I'm reading this, you are basically saying the same as https://forums.autodesk.com/t5/revit-ideas/view-template-include-subcomponent-from-other-template/id... I think?  Your thoughts?  

[s1.young]

@Ric_Weber  Yes very similar to that but I think just having a single based on template link would be a simpler integration as the linked template for each parameter is possibly replacing an already complex system to maintain with another complex one. Having an overall parent child template relationship keeps it as one source driving the children.

I had actually seen that entry and was meaning to reference it but got caught up in my explanation and forgot to include the link. 🤦

---

@s1.young wrote:

The Concept: Introduce a "Based on" or "Parent Template" logic to View Templates, similar to how Paragraph Styles function in InDesign or Word. This would allow a "Parent" template to define global standards (like Detail Level or Model Displays), while "Child" templates inherit those settings and only override specific parameters (like V/G Overrides for a specific discipline).

The Workflow:

1. Inheritance Toggle: Each parameter within a View Template would have an "Inherit from Parent" checkbox.

2. Global Updates: Changing the Font or Scale in a "Parent" template would instantly push that update to 50 "Child" templates, provided those children haven't explicitly overridden that specific parameter.

3. Visual Cues: Parameters that are being overridden at the child level should be highlighted (e.g., bold text or a blue icon) to show they no longer follow the parent.

Why it’s needed: Currently, managing View Templates in large projects is a manual, error-prone process. If a firm decides to change the "Phase Filter" across all 20 of their Plan View templates, a BIM Manager must manually open every single template. Hierarchical templates would reduce maintenance time by 90% and ensure project-wide graphic consistency.

---

1. _

[cprettyman]

I think this is a very strong idea.

We use a partial workaround on some large projects, but it is definitely less than ideal.

In our case, we need several types of overall, partial, and enlarged plans. Some settings are consistent across all views of a given scale or purpose, such as scale, and many V/G settings for Model Categories, Annotation Categories, Imported Categories, Worksets, and Revit Links. At the same time, different types of enlarged or partial plans often need different sets of filters. In practice, that means two overlapping kinds of variation: scale-based settings and filter-based settings.

In one real example, we had three scale-based groups and nine different filter sets, and all combinations were needed. If every combination required its own template, that would mean 27 view templates.

Our workaround was to create:

• 3 templates for the scale-based groups, with V/G Overrides Filters unchecked under Include

• 9 templates for the filter sets, with everything unchecked except V/G Overrides Filters

We then assign one of the three scale-based templates to the view, and apply one of the filter-only templates. That lets us mix and match, so instead of maintaining 27 templates, we only maintain 12.

That approach can help, and the same logic could be used for other combinations of properties, with one group controlled by the assigned template and another pushed by applying a second template.

But the drawbacks are significant:

• it is really only a simple two-level workaround, not true inheritance

• it depends heavily on which settings are more likely to change during the project

• if the “applied” settings change often, the workflow becomes cumbersome and error-prone

• applying template properties is still a manual action, so it does not provide the reliability of a true parent/child relationship

So while there is a workaround, I think your proposal is much stronger and would be a real improvement to template management in Revit.

[s1.young]

@cprettyman 

I get the system, and it is very resourceful.  Am I right in thinking you have to would have to ping-pong between the Scale-Based templates and Filters to do updates? I'm guessing you return to the Scale-Based template after applying the the Filters one.

It just seems unnecessarily complicated for something that could be so simple. There are numerous layout packages, such as InDesign/Word/Affinity, that have the perfect framework to replicate.

Thinking about it, the same Parent/Child framework could be applied to any family type in Revit. For example, if you had 5 different window widths and heights that you all wanted to inherit all other parameters like head height, materials, etc. You could make the children inherit all parameters except the width and height. Then, updating materials and head height across types would only require updating the parent to update all inherited parameters.

I have created quick Grasshopper scripts in the past to update bulk parameters across family types, but this would be a huge game-changer in family type management.