One Rack Shape or Separately Schedulable Components? Specify the Revit Family You Need

Compare the schedule task behind the rack view

Two proposed rack families can look equally useful in an elevation. Both show the enclosure and three internal equipment modules. Offer A promises the assembled rack representation. Offer B also promises that the recipient can schedule the modules individually. If the buyer needs a module quantity report, the second promise describes a material difference in the deliverable. More elaborate geometry in Offer A would not, by itself, supply that result.

A Revit family defines related geometry and properties, called parameters. Family types describe variations within that definition. An instance is an occurrence created using a family and type. One module type can therefore have several instances; the type name alone is not a quantity.

Nesting means placing one family inside another. In this article, the parent is the rack family and the children are the nested module families. Shared describes the nested family's behavior when that combined family is used in a project. These terms explain the model structure the buyer needs to evaluate, rather than the physical detail visible in a rendering.

References: [A1][A2]

Understand what sharing the nested family changes

Autodesk's Revit 2026 documentation distinguishes the two arrangements directly. A nonshared nested component acts with the rest of the parent as one unit and cannot be scheduled separately. A shared nested component can be scheduled separately. Nesting supplies the composition; sharing changes whether the child can participate individually in the schedule.

This is a behavior to demonstrate in the project, rather than infer from a family name or a detailed view. A rack with recognizable module shapes does not establish that those shapes are separately schedulable module instances. Ask the proposed author to identify which children are actual nested families and which of those are shared.

Category also matters. Autodesk explains that nested shared instances in different categories appear in their respective schedules, with the components appearing together in a multi-category schedule in its documented arrangement. Do not assume that the rack parent and every module will appear in the same equipment schedule. Agree the relevant parent and child categories, then ask to see the intended report.

References: [A2][A3]

Separate eligible instances from displayed rows

Separate scheduling does not guarantee a separate displayed row for every component. Autodesk's Revit 2026 sorting examples show an itemized schedule listing individual instances and a summary schedule grouping families and types without a line for every item. A short report can therefore describe several instances. Counting its visible data rows is not a reliable substitute for understanding its quantity basis.

Filters address another question: which elements appear at all. Autodesk documents filters that limit the schedule's displayed data. A shared component can be absent from a particular report because it does not meet that report's selection criteria. That absence is different from a nonshared child being unavailable for separate scheduling.

Check the family structure, the schedule's category and filters, and its grouping and itemization. Changing aggregation cannot make a nonshared nested child independently schedulable. Conversely, rebuilding the family may be unnecessary when the required shared instances already exist but the report groups or excludes them. Ask the author to explain the cause before pricing the remedy.

References: [A2][A4][A5]

Follow two rack parents and six module instances

Consider a fictional purchase comparison with two parent rack instances, R-A and R-B. Each contains three instances of the same nested module type, M. Offer S stipulates that all six module instances are shared and that the intended component schedule includes their category and admits all six through its filters. The child population is two racks multiplied by three modules per rack: six module instances. This is an original arithmetic example; no Revit file or schedule was run.

Those six instances are candidates for individual scheduling under the stipulated structure. The returned report still needs its grouping, itemization and quantity presentation defined. Six instances do not promise six displayed rows. The two parent rack instances form a separate population, whose inclusion must also be intentional; adding them does not create eight modules.

Offer N shows the same arrangement but stipulates that none of its nested modules is shared. It does not provide six separately schedulable child instances through that nesting. A parent schedule can describe the rack assemblies, but its displayed rows still depend on the schedule setup. An author could separately document that each assembly contains three modules; that calculated contents statement is a different deliverable from scheduling the six child instances.

For a buyer who needs individually identifiable module records, S addresses the necessary nesting behavior more directly. For a buyer who only needs to locate and count complete supplied rack assemblies, N may satisfy the task. Compare the demonstrated outputs against that purpose.

References: [A2][A3][A4]

Choose the purchase unit before using the quantities

Keep the fictional six-module population, but now stipulate that each purchased rack assembly includes its three modules. The requirement is two complete assemblies. Six scheduled module instances explain their contents; they are not six additional module purchases. If a material list treats both the complete assemblies and their included modules as independent requirements, it counts the same supplied contents twice.

A different supply arrangement could require two empty rack frames and six separately supplied modules. That would need an explicit definition of what the frame line includes and excludes. The model's shared setting does not choose between these commercial arrangements. Neither visual detail nor separate scheduling establishes a product code, kit contents or a supplier's offer.

State whether each report is counting complete assemblies, contained components or separately required materials. Preserve the assembly-to-component relationship when preparing the material view. The existing cable-schedule and BOM article covers broader material reconciliation; the particular risk here is that making nested components schedulable exposes another population that must be interpreted before it becomes a requirement.

Request a family and schedule demonstration

Before commissioning the full rack population, ask the proposed author for a representative family placed in the intended Revit environment, together with the schedule and sample quantity output the recipient needs. Use the actual target software version. Identify the parent and child types, shared status, categories, selection criteria, required fields and grouping. Ask the recipient to evaluate that output against the intended task.

For the fictional case, the useful demonstration would account for both parent instances and all six stipulated child instances, while showing which population each report includes. If the recipient needs to distinguish the modules within each rack, ask how the output associates each module with its parent. Do not assume that the needed rack identifier or material reference appears in a child's scheduled fields merely because the child is nested there. Have the author demonstrate the actual information relationship.

Inspect an itemized view when instance traceability matters, and the intended summary when grouped quantities are the deliverable. If a quantity export is part of the purchase, review that sample output too: can its reader recover the intended unit, population and assembly-content distinction? A screenshot of the rack cannot answer those questions.

This is a review of model information for a defined use. It does not establish installed quantities or authorize fabrication or field work.

References: [A1][A2][A4][A5]

Bring the quantity task to the planning discussion

Leviathan's Physical Infrastructure Planning & CAD service is the existing place to discuss rack layouts, schedules and material-documentation requirements. Use the project inquiry to describe whether your team needs complete rack counts, separately identifiable components, a grouped material requirement or a combination. Bring an authorized representative input and explain what the recipient must obtain from the output.

Actual authoring software, production resources, reviewers and supported file formats are confirmed for the engagement before a native Revit deliverable is committed. A focused request is easier to evaluate: identify the components that must schedule separately, the quantity unit the recipient will use, and the representative demonstration that will show the result.