Shared Family Parameters Break Circuit Naming Across a Linked Model
Your team built a custom family for a combination emergency/eglomise wall unit with a shared parameter for Circuit Description. The parameter is added to the family and to the project, and the family is nested inside a host family used for 60 devices. After the electrical model is linked into the architect's model for coordination, the architect reports that circuit descriptions in schedules are blank for all 60 devices. In your model the descriptions appear correctly. Separately, a lighting fixture family with a shared nested annotation has stopped rotating with the host after a family update.
1. Explain why the shared parameter values are blank in the architect's model and why the nested annotation no longer rotates, then describe the fix for each.
Read the worked answer
Shared parameters are only shared by name and GUID when the parameter definition exists in the receiving project. The architect's model does not contain your shared parameter definition, and Revit does not transfer project parameter definitions through a link. Schedules in the architect's model therefore have no field to read. The values are not lost; they are simply not exposed. Fix: export the shared parameter file and have the architect add the same parameter (same GUID) to the appropriate category and bind it in the schedule. Alternatively, publish the data through a schedule exported from your model or through IFC/NWD with the property mapped.
The nested annotation rotation issue is a family-editing problem, not a linking problem. An annotation nested into a host family rotates only if it is placed on a reference plane or with an alignment constraint that follows the host's rotation, and only if the nested family's work plane is set correctly. After the update, the nested element was likely re-placed on a fixed work plane or lost its locked alignment. Fix: edit the host family, verify the nested annotation's work plane is the host reference plane, re-align and lock it, then reload into the project and retest rotation in a plan view.
2. What governance would you put in place so future family updates do not silently break circuit data or annotation behavior?
Read the worked answer
Establish a single shared parameter file stored on the network and referenced by every discipline model. Maintain a parameter register listing name, GUID, data type, and which categories are bound.
Require family authors to test in a sandbox project that contains the full shared parameter set before publishing. Add a QA checklist: parameter present, correct GUID, values visible in schedule, annotation rotates, and nested elements flex without constraint errors.
Version families with a naming convention and a change log, and publish only from a controlled library folder rather than ad hoc desktop copies. When a family is updated, reload into a test model first, run the panel schedule and fixture schedule, and compare against the prior version.
For cross-discipline coordination, agree in the BIM execution plan which parameters are exchanged and how they are mapped. Document the mapping so the architect's team can bind the same definitions.