Primary Menu

Best Practices with Revit Groups: Rule #1

Revit Model Groups are a wonderful thing. They allow capturing repetition in the building model, and provide a way to tag through the groups, maintaining unique instance properties of the contained elements for scheduling. Determining best practices for Revit Model Groups has been challenging and a moving target. Some old rules no longer apply. I love the fact that The Factory has been making strides in improving group functionality and stability from release to release. For instance, mirroring works very reliably in Revit today, versus 2 years ago it was verboten. Here are my first two good rules to begin with that are hard and fast (until some new feature makes them obsolete one day), and they are:

Constraints on elements will bust the group, whenever the conditions of the constraints change. My best example of this is: You cannot have walls with level-attached tops inside a group if any floors you wish to place those groups on another level that has a different floor to floor height.

Instances of Groups must be composed of identical elements. Like an AutoCAD block, if you remove an element from one, it is no longer contained in any other instances of that group. (R.I.P. April 15, 2008, with the ability to Exclude elements from an instance of a group – Hooray!) But, there’s a catch. Beware of hosted elements.

For this article, let’s focus on Rule #1.

The sneaky thing is: You may observe the behavior for walls inside groups is benign. As you may know, elements such as a wall can be given either an explicit height, or have its upper extent constrained to a level, floor or roof element, or a reference plane. Since nested elements must remain consistent in every instance of a group, those which contain walls that are top-constrained to a level, attempt to respect the resultant height of the constraint to the next adjacent level. At least the walls do not break the group if placed on levels whose floor-to-floor height varies. An override for Top extension is auto-magically placed on the new nested wall instances to keep them consistent, and no warnings are displayed. You have to be mindful of what really happened. A properties override, if you will, was assigned to the new walls during their creation. Looking at the walls from an section or elevation may not show any difference. The original constraints are still present so… can we do it?

Not So Fast! Remember this: If you attempt to change the height of your levels, you will be in a severe amount of pain. The feared warning will come up stating: “Group instances of the same type do not contain identical members.” When you are presented with the option to Fix Groups… Revit simply asks you to ungroup or make unique groups for the naughty thing we just did. Rule number 2 still applies.

Recommendation: Be cautious

So, it might be best to create groups for large room-based compositions which include walls to be designated by the level the were created for. New groups should be created for the other levels, and so on… You should ask yourself whether the walls are helping or hurting you if inside a group. I’m not saying you shouldn’t, but you should consider the consequences. Because of all this chicanery, I still recommend for cases such as demising walls, or any other conditions where walls are to be stacked one on top of the other, don’t model these per floor, and certainly don’t place them in groups. You may be better served to model them with a single-spanning wall starting on the lowest level and connected to its uppermost limit. This is easier to make changes, and accomplishes an efficiency with less geometry in the model. Think shaft walls, plumbing chases, and tenant separation walls, as these are critical to be sure they actually stack. Unless you are building a construct-ability model, don’t build it the way it will be constructed in reality, but to convey design intent. Structural engineers and contractors will probably argue with me on this one, but at least in the early stages of design, it is a far easier thing to manage the building model this way.

Got any best practices of your own that you wish to share? Feel free to add comments, or drop me a note from the contact me page.

Share this:

27 comments on “Best Practices with Revit Groups: Rule #1”

I can’t believe you guys accept these kind of bugs in a software package! Groups and blocks are supposed to be part of any modern CAD package, not some wonderful extra feature or add-on. Revit is being touted as the best software out there and only recently could you successfully mirror groups?! And changing the level of a group causes problems when drawing in Revit is based on levels?!

We don’t accept it, but I have since learned to live with the fact that all software has shortcomings. For all that Revit excels at so thoroughly well, since there are many ways to represent repetition, including families, links, and others, it ain’t so bad.

Having constrain-based, parametric modeling, which also allows sustainable design analysis makes me happy. The ability to simultaneously have multiple designers work on a single file across the WAN on both ends on the country or the opposite side of the world in real time makes the firm happy.

I am working on a multiresidential townhouse project that is built on a slope. I have my unit types as groups defined off to the right of the site. I am having no end of grief with placing the groups at the proper rotation and elevation without them fixing themselves, uniquing themselves or deleting themselves. Some groups refuse to be copied, one refused to rotate 180 degrees but let me mirror it twice for the same result. The thing is I would like my groups to not try and heal themselves at each transform until they are in their proper place. For my next project I am trying to make each unit as a separate project linked into each building as a separate project linked into the site plan. Grandfather, father, child. It looks promising. But I am hoping I can fix these groups in this project so I don’t have to redraw them.
Do you have any suggestions on creating a three storey group that does not mind being raised and lowered to other levels?

Groups are so touchy. This I will agree. When their contents are complex, and contain many interrelationships with each other, they don’t always behave as expected. For instance, rotating or mirroring a group that contains a gridded ceiling gets very confused. What I have begun to tell designers is that the preference for repeatable elements in the model are: Family, Linked Model, then Group. I will be exploring the Assembly feature in Revit Architecture 2012 to see if there is a new opportunity to rethink this.

So since your collections of repeating elements contain walls, linked Revit models would be your best approach. Thankfully, The Factory gave us the ability to save a group as a RVT file, which can then be linked in. When projects become very large, the other advantage of this approach is you can document and create sheets for the units as a standalone file. You can also manage how much detail is brought into the main project, by placing those things you do not need to see in the assembled building into their own worksets, and choose not to include those worksets when linking.

This approach goes back to the way we did unit plans back in AutoCAD, and later ADT at the first firm I worked almost 15 years ago in the little city of Newburyport, Massachusetts. Check it out if your ever travelling. It’s a great little New England town. Stop in to EGA Architects, and tell them I said hey!

Thanks for the reply. The second townhouse project has units linked into buildings which are linked into the site. It seems to be behaving very well except that my site plan is littered with refrigerators, closet shelves, and vanity counters from all the floors. It seems these don’t like to behave with the change in height (up 83 ft.). I will take your advice and place these into their own workset at the unit level so I can turn them off on the site plan. Otherwise, this is definitely the way to do these townhouse projects.
I started AutoCAD when they just added the DIM command for dimensions and they still had only the 7 named colors. I was on AutoDesk Architecture when it was still Softdesk version 7. The last place I worked at, they used an AutoCAD / Sketchup combination for all their drawings and it worked fine. Now this place I am at is a Revit only shop and I have to get used to the amount of control Revit has over the database. I am still finding my way!

Since you guys are talking groups and links (or were a while back). We are having a couple of issues. Maybe you can provide insight.

1. Links: We link units into a building and then the building into the site. The site file has become impossibly difficult to deal with. We have about 20 unit types and around 450 instances of those 20 types. Is it normal to have this much difficulty with a double linked file? Our site file crashes often and is very slow. There is definiltey something wrong and I am troubleshooting as best I can.
2. Groups: We have one floor of the building that seems to “ungroup” the groups that are placed on that floor. The groups are still identified as groups when you try to change a wall or element but each individual element looks detached from the group. You don’t get the normal group box when hovering over the group. You still get the box in a 3D view but not in plan. Any thoughts?

1) Regarding the multiple links, using a container file to bring them into the site makes sense, however, unless you are using shared coordinates, that behavior is difficult to investigate.

I would expect that you may need to recreate one of the central files, or at least open them up individually with Audit enabled.

2) It’s possible that the view was corrupt, and that was why it was displaying differently in 3D versus plan.

One situation I have come across frequently is elements such as furniture become hosted to a floor, versus associated with the level datum. This can happen even when families that are not designed to be hosted are placed – very unpredictable.

When the floor face is hosting members of a group, it becomes very difficult to place the group on a different level, as those elements belonging within the new group instance become “sticky” to the original floor. The only way around this is to ensure the floor category is not visible while placing the original elements you intend to group, or place them off to the side, outside the building and then move into position.

THANK YOU for this post. I had been struggling for weeks and weeks over groups in Revit, and have now quickly fixed my problem by turning them all into linked Revit files. Most Revit discussion boards are incredibly unhelpful and complicated, so I greatly appreciated your concise yet thorough explanation. life saver!

Has any one ever tried to work on groups in a file outside of the main model, and then use the reload group from feature in the main model to update the groups? I am thinking this could eliminate or greatly reduce the frequency that group either want to break or duplicate & rename.Thoughts? Groups that break become a huge issue when you are annotating late in the deign process : /

Thanks Sean for your insightful article, we are currently developing a 4 quadrant multi-residental project with 1200 apartments of over 60 types.

At this stage partition and external floors are modelled using extensive grouping and differing levels heights. Fortunately we only have 2 floor heights, so for a typical level there will be 2 instances of each group. We use a strict group naming convention, consisting of GRPTYPE_QUADRANT_BUILDING_LEVEL_ELEVATION… eg FACADE_Q1_A_L06_NTH.

Like others have said, hosted elements are troublesome in groups. Ideally with windows and doors we try to keeep them in the group. However the design calls for A-B-C variations in window layouts. Using exclude is a no-no as the excluded windows still exist in schedules. So we create a group for each pattern.

However, have you ever tried moving a wall which hosts seperately grouped windows? It is a pain. There are two methods we are aware of:
1. move the group origin point to the wall or 2. draw a new wall (with Create Similar) and copy/move the window group to the new wall.

But the real issue at hand is how to approach grouping apartment internals, now that the project is moving from DA into construction. Up until now the internals have been drawn in AutoCAD with blocks and xrefs and then linked into Revit.

Now is the time to model internal walls and fixtures so that they can be scheduled. Do we use groups or linked models?

From what I have read here linked models are far more flexible, especially with Worksets to control the level of detail in different drawing scales. But what about load time? With over 60 apartment types, that is a lot of links!

I was interested to hear about Shawn’s linking issues with only 450 apartments and 20 types. It is a pity that he never replied to your suggestions, as I would like to know if he actually had file corruption or if the load times become unmanageable.

At present we have a Master file for the site, 4 files one for each quadrant of the site and then tower files where there are repeating towers (these towers can be mirrored. Apartments types can also exist in more than one quadrant.

Have you had experience with using linked files to this degree? I’m interested to know about model load times and impacts on viewing the model in 3D.

I am going through the process of linking in unit files into our floor plans. Typically, we model the skin as a separate workset and our windows and exterior doors are hosted onto these walls. The issue I am coming across is that the exterior stud wall that is a part of the link and the exterior brick wall cannot join, thus the window and door openings do not punch through.

If I understand you correctly, you are asking if walls will join across links? The current functionality in Revit does not give us this behavior. What you might want to do is keep all of the exterior skin elements in a single ‘shell’ model. Then, the units would have the interior walls and elements only. You may need to add room boundary lines in the units, unless you also link the shell back into the unit files.

Thanks for a really useful and interesting blog. I see it’s been a couple of years since the last post so I’m wondering what the general consensus is currently on links vs groups for apartment layouts? We are working on Revit 2015.

We are about to embark on a large residential scheme consisting of multiple unit types. 1, 2 and 3 bed, which will then be broken down into further deviations. Floor to floor heights should be fairly consistent.

Somewhat like Frank’s project, we will have 4 blocks, each containing a mix of units. I am planning to create a separate model for each block, then link into a site model using shared coordinates.

My research so far has lead me towards creating groups for each unit type. It seems this will be more productive, certainly during initial design stages. Not having to jump in and out of different models will speed workflow. One issue I am having is that when I move an external wall (modelled full height of scheme) the internal walls contained in the group don’t move and therefore the ‘room’ gets deleted. This means creating new rooms and re-labelling to suit after updating the group. Room and area schedules are critical to this project. Is there a way to lock the internal walls in the group to the external wall? Or is the snag with having to remake the room just something we have to deal with?

I just did a test creating a linked apartment interior layout, to see if I could create my ‘rooms’ in there, but it seems you can’t lock area boundaries to linked models.

Is 2017 now and getting ready to start a 5 story building with about 30 Unit types. Based on what I read above – very usefull by the way – I’m planing to link the Units and have them being worked as separate models 9 I’m going to have a team of 3 rookies:/) I will have work sets to keep the main model clean and light. It’s been a while, is this still the best option?

I still think groups or links are the best options. It is a matter of preference really. Links have the disadvantage of the adjoining walls not cleaning up, however that can be a graphic tradeoff for the lightness of having independent models. However you now have to carefully manage changes to content and distribute into each unit type. Both links and groups mirror and rotate well in the container model to show the whole project for visualization or printing large scale plans. I hope that makes sense.

I agree, keep the units as separate models. If you link, I recommend using shared coordinates. I like the 2017 features for Unload for Me, which will allow you to open the main model in a lightweight manner and choose what you want to see. We do this for hospitals with hundreds of room types in the millions of square feet. It should work equally well here.

Groups will still work as well, as you can reload from an external RVT file – although is a bit more maintenance and you have to worry about content definitions being the same in all models or the main (container) model definitions for families will take precedent.

I have tried looking into different options to deal with multiple level floor plans that are identical inside a single building, in this case a hotel refurbishment project, where four levels of eight are identical. The options have been between linking or grouping identical plans and then copying them to similar levels to accommodate easy design changes. The group/link to be copied includes only per floor internal walls, doors and ceilings along with furniture. A few observations I have come across so far:

Groups for entire floor plates become easily too large and have the risk of failing when finishing the group, in this sense links seem to be an answer.
As minus points to links and for us a major obstacle are:

– Objects in links can be tagged in the host project, but when multiple links inside the host are included, tagging of e.g doors with unique door codes can not be done (all doors in copied links are seen as identical instances by Revit)

– The tagging issue has a workaround, where the tag family is edited so that it uses a prefix of the level and each floor has a separate tag. For example: 2nd floor tag with prefix “2”, 3rd floor tag with prefix “3” etc, so a door with a code 003 becomes 2003 and 3003 on respective levels, which makes it kind of work, but…

– A more bigger issue is the problem with scheduling, schedules can not be sorted by level for the objects in links and also, the workaround that can be used for tags does not apply to schedules – no prefix can be added to the schedule to make e.g. each door unique

– IFC export is no longer possible with linked floor layouts, because Revit enables only links to be exported as separate IFC files, and we need to have a single file of the entire building.

I understand the benefits of links, but for now these negative aspects seem to overcome them. On the other hand using big groups for entire floor plans does not seem like a safe option, in fear of losing work after >30min group editing and then Revit finding an issue! 🙂

For documentation purposes, I would tend to do all the plan annotation and associated sheets inside the floorplate model and link into the project. Then create a schedule that indicates it is representative of typical floors 4-8.

I wish there were a better workflow unless you can think of a way to use global parameters to help.

OK, thanks for your input! My first thought would be to keep only Model objects in the linked files, and all annotations as well as rooms, room tags etc would be in the host model.

Is there a particular reason why annotations and even sheets should be in the linked file? It seems that it would be easier to manage annotations, rooms, sheets and printing when these are in the host model. The idea of a typical floor schedule is something I will definately look into.

Global parameters for now have not yielded any answer (unfortunately I’m also not that familiar with them).