Family Parameter Breaks When Nested Profile Changes
A structural team built a parametric pile-cap family with a nested pile family. The pile cap has a parameter 'Pile Spacing' that drives an array of nested piles. A project uses the family in 60 locations. After the family author changes the nested pile's diameter from a type parameter to an instance parameter, 22 of the 60 placed pile caps report 'constraints are not satisfied' and the array count resets to 2. The author wants to reload the family into the project to fix it, but the project is mid-issue and the model is workshared.
1. Explain why changing the nested parameter type broke placements, and assess the reload plan.
Read the worked answer
Changing the nested pile diameter from a type parameter to an instance parameter changes the family's parameter contract. Placements that were driven by the type-level value no longer receive the same input, and the array, which depends on Pile Spacing and the nested geometry, can no longer resolve, so the constraint fails and the count falls back to its default. The 22 failures are the placements whose array or spacing logic depended on the old contract; the other 38 may have had overrides or different spacing that survived.
Reloading mid-issue on a workshared model is risky because a reload propagates to every user and can overwrite local overrides. Before reloading:
- Reproduce the failure in a test project with a copy of the family.
- Decide whether the instance/type change is actually needed; if not, revert it.
- If needed, add a migration path so existing placements keep valid values.
- Reload only after the team is notified and syncs are coordinated, and verify a sample of placements afterward.
The judgment is that family reloads are project-wide events and should be tested and scheduled, not used as a live fix.
2. What family-design change would make future parameter edits safer?
Read the worked answer
Design the family so its parameter contract is stable and its failure modes are visible. Options:
- Keep driving dimensions as type parameters unless there is a clear instance-level need, and document the contract.
- Add validation formulas or conditional constraints so an invalid combination produces a clear warning rather than a silent reset.
- Use a shared parameter set and a consistent naming convention so project schedules and tags survive edits.
- Version the family and keep a changelog so the team knows when a reload changes behavior.
- Test the family in a sandbox project with several placements before publishing.
The tradeoff is that stricter validation can make the family harder to flex for unusual conditions, so the author should decide which parameters truly need instance control. The exam-relevant reasoning is that family edits are interface changes to the project, and the author owns the migration impact.