Dependent views are rarely needed but can be useful at times. The Revit help docs describe the typical uses pretty well here: About Dependent Views.

In short they have 2 principle applications:

  • Large views (plans / elevations / RCPs) that need to be broken down into smaller sections. This is common in healthcare projects, for example. Dependent views allow you to work on the primary view and disseminate the changes to the partial views on sheets and vice versa.
  • You need to place a view on more than one sheet

I recommend going through the limitations of these view types in the link above, because they are many. I'm not writing this to regurgitate the Revit help docs, but rather to discuss a more complex potential use case for these views and some issues that may arise if you decide to go this direction.

Hypothetical Project

You are designing two (almost) identical buildings for the same client on two sites. I have worked in exactly this way in the past and it presented some interesting challenges. Naturally you are not going to draw both buildings from scratch - there are clear efficiencies to be found. That said, both buildings need unique drawing packages for a few reasons:

  • Stamped submissions to authorities in two municipalities
  • The projects require unique titleblocks (locations, project numbers, titles, etc.)
  • The projects have unique sites and geotechnical conditions, which will undoubtedly affect (at least) below-grade structure and servicing.
  • The unique sites probably mean unique fire route, driveway, parking, etc.
  • Likely two contractors requiring stamped contract documents

Regardless, the buildings will have plenty in common:

  • Assemblies
  • Exterior / interior materials
  • Building Plans / Elevations / Sections
  • Wall sections (above-grade at least)
  • Doors / Windows / Screens / Casework
  • Funiture / Fixtures / Equipment
  • Finishes

If you are working for a client who wants two identical buildings, they probably also want the drawings done yesterday (and for free), so it's important to quickly come up with a plan for how to tackle this scenario. A project like this has many potential "lessons learned" but I'm only covering a thought process for organizing the sheet sets and limiting rework. One of the choices is significantly less work, but will depend on how much of each building is unique and the requirements of your client:

OPTION 1 (less efficient):

  • Establish sheet sets for each of the buildings in the same model and a sheet numbering system that is unique for the two buildings, as sheet numbers in Revit must be unique. For example X-A-100 & Y-A-100 might be the Level 1 floor plan for building X and building Y respectively.
  • Duplicate all major building plan / elevation / section views as dependents and place them on their respective sheets. This way any change to one will necessarily update the other. You should only be working on one set of views / sheets, as the other will be necessarily identical.
  • Call out all identical views (wall sections, interior elevations, millwork drawings, details views, etc and duplicate the views as dependent, placing them on their unique sheets as required.
  • At face value, this seems like a lot of set-up work, but should work perfectly. The major advantage of this solution is that you can create revisions for the two projects and apply them properly to each individual set of drawings. For two projects which are being tendered at different times, this might be very important for your client. Having worked in this way, however, there are some major drawbacks as the drawing package increases in complexity:

Drawbacks:

You cannot assign different design options to dependent views, so you still need to create unique views for parts of the site or building where the design differs.

You cannot assign different view templates or visibility settings to dependent views. Remember this. Before going down this road, re-read Autodesk's list of visibility constraints for views duplicated as dependent:

Display model
Detail Level
Visibility settings
Visual Style
Graphic Display Options
Hide at scales coarser than
Underlay
Underlay orientation
Wall Join Display
Discipline
Color Scheme Location
Color Scheme
Phase Filter
Phase
Associated Level
View Template
View Range
Depth Clipping
Far Clipping
Far Clip Offset

Example of a major issue: EVERY view callout will be visible in the parent view from which it came. For example, if you call-out detail view 1/X-A-700 from your Level 1 floor plan and duplicate it as dependent to create detail view 1/Y-A-700, BOTH of these callouts will be visible in your floor plan. When I ran into this issue, my genius solution was to create a filter for each view that would filter out all views that I didn't want to see. Impossible! View filters will affect both views identically. The ONLY way I have found to fix this issue is to select all of the view callouts you don't want to see and save them in a selection group, adding any additional views callouts to it as required. You ARE able to hide elements by view, which will not affect the other views. This is very risky and will be a constant chore throughout the life of the project. If you don't have a very tight drafting team, I would advise against this route. You've been warned!

You can set Shared and Project parameters independently for dependent views, but I have yet to figure out a way to use this to influence the graphic display options of the views. There may be a creative dynamo solution whereby views with a certain prefix are not visible in views with the same prefix - I will experiment and write a follow-up if that works.

OPTION 2 (more efficient):

  • Do not establish unique sheet sets for the buildings, but rather create unique titleblocks for each of the two buildings and replace them for printing only. Create presets for printing and put one person in charge of the print/export process.
  • If there are very minor design changes for the two buildings, it may mean establishing a few design options to reflect the differences between the buildings and assigning them to unique views. For example, you may have a "Site X / Site Y" design option and another to reflect some minor interior differences @ the Level 1 entrance. Perhaps only the site plans, building elevations, and building sections are unique enough to warrant fully unique views, even if the differences are only .
  • If your site plan for Building X is A-100, perhaps your site plan for Building Y is A-110. A sheet of site details (bollards, curb cuts, retaining walls, planters, etc) might then be identical for both projects, so that can be sheet A-120 and can be used in both print packages. Adjust for your standard numbering system.

Drawbacks:

The major drawback of this strategy is that you are dealing with one set of sheets, regardless of switching between titleblock families. This means that you cannot control revisions independently for the two buildings. There may be a creative way to filter them out in the titleblock family, but the real solution may be to apply revisions to the sheet sets after printing in Bluebeam or Acrobat. Alternatively, you can create a prefix for revisions, for example:

Sheet: A-100 - LEVEL 1 FLOOR PLAN

Revision 1: 2019 01 10 - Bldg X - Issued for Building Permit

Revision 2: 2019 03 25 - Bldg Y - Issued for Building Permit

A system like this might take some explaining to the various stakeholders on the project, so it's up to you if this strategy will suffice or if you'll need to create a more custom solution. I'll look into workarounds for this and will write a follow-up. Either way, I think I would prefer this process @ each project milestone than the headaches experienced using Option 1.