Group Load Order Breaking Constraints

[KaB90_com]

I Have several project files with unique kitchens intended to be inserted into a project as groups (this is non-negotiable).  The files consist of like families with shared parameters.  Everything works beautifully... depending on which kitchen is loaded first.  For reasons beyond my comprehension if they are loaded into a new blank file in the wrong order constraints for half of the groups will break.  Naming rights to my first born goes to anyone who can help me fix this.

[SteveKStafford]

What constraints "break"? I load both of them into a Revit 2025 project file and other than a warning about the file being more than 10MB it loaded fine and I placed them and swapped groups back and forth. I'll try it in Revit 2022 since the files are in that version but I didn't know at first until I already had 2025 running.

[SteveKStafford]

Okay, when I use Revit 2022, load B first and then load A I get a constraints warning. It didn't warn when loading A first and then B. When I look at the warning details for loading A it's related to a cabinet and alignment and dimension style. When I edit Kitchen A and remove the constraints associate with the cabinet (see image) then I can load Kitchen A second without a warning. I'm not sure why those constraints are an issue for the loading process.

Technically I don't think you need any of the constraints being used in the kitchen layouts since they aren't getting altered in the parent project? If they are then you'd likely need to break constraints to "massage" their configuration anyway.

If you use Reveal Constraints in the kitchen models you can see all of them and decide which of them or any of them are important to you.

[KaB90_com]

They're all necessary.  The fixtures can be toggled and the cabinetry needs to adjust accordingly.  I'd hoped for a 2022 solution, but if upgrading the files is the cost of admission I'll gladly pay it.  Unfortunately I don't think I can give the first name for a workaround, but the middle name is yours if you have a preference.

Thanks Steve!

[SteveKStafford]

I double checked, the constraint warning loading into a project still happens in 2025.2 so don't upgrade for that reason, plenty of other reasons to do it...just not that.

I suspect that the constraints aren't the issue themselves, rather "what" the constraints are associated with. As in the family editor, Revit prefers that constraints are tied to reference planes. So perhaps you can create the "bones" of the layout with reference planes that are constrained and then your cabinets are aligned and locked to them. Also make sure you don't have constraints that contradict each other in terms of how the content can flex. If you change the size of one cabinet as a test, do the other cabinets adjust correctly without a warning?

[KaB90_com]

I have 7 of these files and they all work perfectly if loaded in a particular order (it just so happens to be the order in which they were built which is why I didn't realize this failing earlier). All of the families are flanked by strong reference planes which I use to constrain them to each other.  I've tried every parameter manipulation I could think of looking for a weak spot to no effect.  I've audited and purged and tried copy/pasting into new files in case there was a corruption also to no effect.  ChatGPT indicated that the fact they break on loading rather than instantiation suggests it's a load setting,

"Since your groups are independent from one another and have no intergroup dependencies, this suggests that the breakage could be due to how Revit handles the constraints and relationships during the load phase."

It further suggested I review the journal for insights, but I couldn't make much sense of them.  I've attached the log in case that's helpful.  The relevant portion is near the bottom.  Just run a search for "Load a file as a group".    The hit that's near the bottom is when the break occurs. That's about as much sense as I could make of it.

I'll gladly provide any other information you might need - this is one stubborn glitch.

[barthbradley]

The issue concerns one Family in both Projects/Groups. KaB90 - CSWK - Type A - Upper - Door_x2.rfa.  It has nothing to do with upgrading or load order.  

Solution: Resolve Warnings in this Family that is in each Project/Group. Note: They are not identical Families as evidenced by the screenshots below. The KaB90 - CSWK - Type A - Upper - Door_x2 Family in Kitchen A is not the same as the The KaB90 - CSWK - Type A - Upper - Door_x2 Family in Kitchen B.  Hence, the reason Revit renames it. I'm guessing they are supposed to be identical, so this will require another solution. Neither solutions are terribly difficult though.  

[KaB90_com]

I'll look into this first thing tomorrow and let you know.

[barthbradley]

---

@KaB90_com wrote:

I'll look into this first thing tomorrow and let you know.

---

If you want to quickly confirm what I'm saying to be true before you dive in - delete the KaB90 - CSWK - Type A - Upper - Door_x2.rfa in both Kitchen A.rvt and Kitchen B.rvt and then Load as Group both Projects - in any order and into any 2022 and up version of Revit.   You'll have a "come-to-Jesus moment".  😉

[KaB90_com]

After beating my head against this for a solid week nothing would make me happier, unfortunately I can confirm a few things.

1) It's not a duplicate family.  For one I haven't been getting a rename error, just constraint breaks (see image "Errors").  I also copy/pasted one of the group's contents into the other and nothing renamed.

2) You did inspire me to do a bit of delete and check around the double uppers and I can confirm the problem is with these two filler pieces (see image "Fillers"), though not with the families themselves. 

The highlighted items are only one of five pairs in this file and when I deleted this one pair the errors went away, then I replaced them with a single extrusion, re-constrained the elements on either side and the errors came back. 

For some reason Revit doesn't want the elements on either side of that yellow line constrained to one another UNLESS Kitchen A gets loaded first.

**Addendum**

My current theory is it's a problem with the Upper x2 family not wanting to be constrained, although I'm not sure how.

[KaB90_com]

Finally some... well not "progress" so much as direction...!

I replaced the upper doubles with a similar family that hasn't been causing any problems and the same thing happened.  Then I replaced it with a completely unrelated double cabinet from a few years back and nothing broke!  I've attached the offending cabinet.  Any insight as to why it doesn't like being constrained would be beyond appreciated.

[SteveKStafford]

Deleting that family also removes the constraints in the project file, (loaded as group) that Revit doesn't like...fwiw. Removing the constraints in Kitchen A file eliminated the loading complaint too.

[SteveKStafford]

FWIW, the family has a warning in Review Warnings (see image).

[barthbradley · Accepted solution]

---

@KaB90_com wrote:

 Any insight...would be beyond appreciated.

---

I would go to BIMObject and download and use Merillat Cabinetry Revit Families in your Kitchen Projects/Groups. I've always liked them. They're built very well. And, nobody's preventing you from changing their names or Identity Data, so if you like "KaB90 - CSWK - Type A - Upper - Door_x2" better than the name "Cabinet-Wall-Merillat-Double_Door", then change it.  😉  

BIM objects - Free download! Merillat Cabinetry | BIMobject

[KaB90_com]

Will do! Thanks for the help!