Welcome to the Revit Ideas Board! Before posting, please read the helpful tips here. Thank you for your Ideas!
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Scope Boxes on Drafting Views & Ability to Create Dependent Drafting Views

Scope Boxes on Drafting Views & Ability to Create Dependent Drafting Views

SEE THE IMAGE BELOW FOR FURTHER REFERENCE: (workflow requirements are outlined below)


1. Ability to Add Scope Boxes to Drafting Views which will easily control Crop Regions which is also required as a controlling function within Drafting Views. 

2. The ability to create Dependent Drafting Views

3. Scope Boxes can be assigned to the Drafting View and the Dependent Drafting Views can be cropped according to the assigned Scope Boxes. 

4. Scope Boxes can be copied from one Drafting View to the next as there are use cases for this. 

5. Drafting View Scope Boxes should also be able to be copied from one project to the next, once again, there are use cases for this too. 




There are various use cases, one of the biggest ones for all MEP Engineers on just about every project is the use of Schematics in Revit, be it from an AutoCAD file linked into a Drafting View or where the Schematics / Single Line Diagrams are drawn out directly in a Drafting View.  


It is required to separate the Drafting View on Multiple Sheets on just about every project. It's extremely time-consuming and error-prone to split elements from a single Drafting View into multiple views. As soon as there are updates, you need to start from the top again (to avoid discrepancies across multiple Drafting Views), followed by separating the Drafting View again.


Similar requests have been made without any major progress from 2016. The consolidated post which I'm referring to can be found HERE


Hopefully, this workflow & requirements get the necessary traction for consideration in future releases. 





Our mechanical engineers with ridiculously large ventilation schematics would love this and I would like it also.


Can't say I ever got on with importing AutoCAD files into Revit for schematics so I do all my schematics in Revit, it's not hard to change over once you realise all the controls are virtually identical.


I agree with your Idea about Dependent Views and the having the ability to Crop them.

However (and, perhaps it's just semantics, but) Scope Boxes would not work for this

You'd definitely need to be able to CROP a View. similar to the way model Views are Cropped (including Crop and Annotation Crop), but not using a Scope Box.

A Scope Box is a 3D, Model element and doesn't mean anything to a Drafting (2D) View.

The main purpose of a Scope Box is to be able to apply the same Box to multiple Views in exactly the same place.

Drafting Views don't have any relation to one another, so using the same Scope Box in two Drafting Views wouldn't make sense.


Completely agree with you @scott_dakin - If you've done a schematic / single line diagram in Revit once or on one project from start to finish, you won't revert back. There are however some firms, especially smaller firms (but some larger ones too) who still link CAD files into drafting views to issue everything out of Revit etc. The problem is still the same for both scenarios where schematics need to split into multiple sheets. As you mentioned, mechanical specifically has huge schematics. 


@dplumb_BWBR - I agree and understand the function of the current Scope Box command. I used "scope box" as a bone which is being thrown to spark some functional solutions relating to how they can be used in Drafting Views to control the Crop (and Annotation Crop) of the views, as outlined in my steps, which will essentially mimic the same functions which end-users are used too. 


To clarify what I meant is where there is a possible introduction of "2D Scope Boxes" which can be used on Drafting Views. These can then be used and copied over to other Drafting Views, Models (or Projects). This way, the consistency of Crops can be controlled. I included a few additional samples below, along with updates to my original images - picked up a typo or two! 🙂 


IDEA_2D Scope_Boxes_on_Drafting_Views_03.jpg  

Let's look at a practical example where this will be useful: The Building below has 11 Floors, which require

11 Schematics for each floor. Due to the size and length of each, they need to be separated on a different amount

of sheets per level. (Scaling down the drafting views is not an option for obvious reasons!)


IDEA_2D Scope_Boxes_on_Drafting_Views_02.jpg

Let's say I started with the worst-case (largest schematic) to inform me of the number of sheets which would be required. Now that I have that information, I generate my "2D Scope Boxes" on that Drafting View and copy them over to the other schematics. This way your Dependant Views of your Drafting Views can be controlled by the "2D Scope Boxes". They don't have a relationship with each other across other drafting views, they merely assist to speed-up and control your crop regions and consistency across various schematics. 


IDEA_2D Scope_Boxes_on_Drafting_Views_04.jpg


 Below is a revised image from my original post. 

IDEA_2D Scope_Boxes_on_Drafting_Views_01.jpg




All makes complete sense. Lets engineer in the ability to create whatever shape crop region we want from the start this time. 🙂


Just as a way to achieve this without anything more added to the program:


Use floor plans. 


We are an M&E consultancy and I have done drainage schematics over 4 sheets in exactly this manner. I appreciate this is technically a work around but because all the items you are drafting are detail items/detail lines, they only show up in that single parent/dependent view. You're complaining about something which already has a solution which as far as I am aware is completely feasible and has no draw backs. 


Please can you all actually go ahead and try this and come back and tell me about the drawbacks because if they are there, I want to know about them!


It's not the way things are supposed to be done and as you say, it is a workaround


No draw backs apart from if somebody deletes your floorplan you lose all your schematics.


I'm not okay with that, sorry.




I personally think if there is a perfectly capable workaround which allows you to do exactly what you want to do without any drawbacks, then there are more important things to focus on with Revit.


If someone deletes your drafting view, is there a different outcome to if they delete a floor plan with your schematic on? 


Also to clarify, I would have my drainage schematic in one floor plan, then my ventilation schematic in a separate floor plan.


If the outcome is the same upon deletion, what part of it are you against? Other than it being a workaround?


Various companies, including Autodesk, are working on ways to link model content data with schematics.


I'm pretty sure this wouldn't work correctly as it is not the intended workflow.


What you are suggesting will work but as mentioned previously, it is not the intended workflow.



Please explain why these companies have any relevance with what viewtype you are drafting your schematics in? From what I have seen, you pick a model element and choose to link it to it's partner in a schematic or vice versa.


To clarify, you are refusing to use this workaround because it is a workaround? Even though as far as those of us in the Revit ideas page are concerned, there is no proper way to do it. Does this mean you are simply not doing it or... what?




So how are you managing to produce schematics which overflow a single sheet?


I create a schematic as a whole and see if it fits on a single sheet.


If it doesn't fit I will duplicate the schematic and remove from each the duplicated sections.


Sometimes I do this splitting up early on, sometimes I do it at the end. It depends on the project, I usually have a good idea before I start whether it will fit or not.


I would normally try to keep my schematics split up by floors so its not usually a huge problem.


I don't want a new method that is different, I want one that is better. What you have suggested will work perfectly well and I'm not knocking you for that.


There are accepted ways of doing things and I prefer to stick to them, it tends to remove the opportunity for errors.


I appreciate your planning.


Is it not a shame to not use a method which, as we have discussed, doesn't have any drawbacks vs the method you currently use, and will actually increase productivity for you and negate your need for such careful planning, which as you admit, cannot account for every situation?


I feel like you're deliberately hindering yourself for an almost 'moral' reason. 


@rudi.roux and @dplumb_BWBR  I would love some feedback from you guys on the method I suggested!


Hi @CFNBen


Thanks for your posts and suggestions. I've been a bit wrapped up over the past week, but managed to find a couple of minutes. I've used your proposed workaround before and have a few things against it, which is why I find this idea to be valid... 


Someone once asked me why a plausible workaround is so bad, and I went on to us the following example:


Imagine buying a car, and you’d expect to get into the car via the driver side door, buckle-up and drive off… Simple right, that’s what you paid for.


Now imagine buying a car, only to realise that the driver side door cannot open, so you have to enter from the passenger side door, struggle over the centre console, finally get in, buckle-up and drive off. 


The output is similar, but the first scenario works as expected while also having the option of using the workaround (getting on on the passenger side door) and the second scenario limits you to one choice which is the workaround, causing much frustration and wasted time along the way. Now imagine if this happens to a significant amount of people globally... 


Saying that something is a viable solution for you is great because it works with your workflows, that does not mean that it’s a workable solution for everyone. Let me explain some of the reason why, from past experiences (bullets below). Please refrain from using user training as the solution for what I mention below because we have on average quite a few new users weekly, same with various other multinational organisations where constant training is unfortunately not feasible. Even experienced users make mistakes, and human-error is not something which will go away, so potential workflow risks need to be mitigated where possible.


  • When a user accidentally changes detail lines to model lines, said model lines are associated with the active Workset. All might look fine for user A, but then user B does the batch printing and might have closed certain Worksets (which model lines are now associated to) before printing. Now information is missing from the schematics and rework is required.
  • Also, now the model lines show up in other discipline models, and they need to ask the MEP engineer to adjust, causing rework and time wasted between both parties. Other disciplines are either required to wait for the updates, until the next share/package or they need to update all their view templates to mitigate this going forward.
  • Users forget to Link CAD files to only be visible on “current views”, with obvious rework implications.
  • When you delete a level (or copy/monitored level), you do not receive a notification of all the elements which will be deleted, only that the level will be deleted. i.e. User might delete a level not knowing that they are about to delete 1000’s of detail lines & items.
  • The reason why I mentioned this is because there are multiple things which need to be managed to ensure that schematic plan views aren’t deleted, not just a direct deletion of a plan view, but also levels which can be deleted via a coordination review, section, 3D views etc… which can essentially lead to the deletion of your schematics. Drafting views is a single element which needs to be managed to mitigate deletion.
  • It has happened that an architect generated an unnecessary level, this was copy/monitored on our side and then said level was removed by the architect, the architect notifies design teams that there is an unnecessary level which has been removed in their model. We receive a coordination review and a user not involved with the schematics accepts the deletion. Guess on which level all our schematics were developed on? Everything deleted… Only realizing this in the 11th hour as the schematics were completed…
  • I’ve had other scenarios where the deletion of schematic elements in a plan was not a problem, but where users ended up deleting 3D model elements. This pretty much happened where for some reason (once again, human error) people applied a different view template to a “schematic plan view” which exposed the 3D model elements and where a selection of a certain area was done and the user continued to press the delete button, thinking that it was clutter (as everything looked like lines… Coarse Detail Level).
  • These are some of my past experiences bouncing off the top of my head. 

I hope this helps clarify things and why I feel the idea can be looked at. There is already the functional capabilities within plan views. Getting the same functionality over in drafting views is a quick win with noticeable benefits to all disciplines. 







Thanks for your reply! It is really interesting to read some of the problems you have. I am from a clearly much smaller company of 35 people and most of the issues you talk about are yet to crop up - however I can definitely see some users in my company doing as you suggested. 


I think I have made the statement that Autodesk shouldn't work on this, and that's not how I feel. I want them to work on it, but I want them to work on other things more as they are bigger issues for myself. 


You're not wrong: until we take humans out of the equation, humans will screw it up. That being said, a lot of the issues you have brought up are people making really bad choices/not being at all skilled at using Revit and that argument could be used for not using Revit at all... 


Some that are more of a problem with the workaround I've suggested are as follows:

  • I don't think you can argue that training isn't part of the process - everyone has to have some training in order to use Revit, it's not a simple program to use. I don't find that to be a particularly valid argument.
  • Levels being deleted - agreed this can be a problem, although surely there is one level that will never be deleted (ground, for instance) and you can maintain that throughout a project. Also you mention people copy monitoring levels when they shouldn't - that's an error that needs to be ironed out in your training. 
  • Worksets being closed - we do not work on projects where worksets need to be closed, although i would argue that a workset for schematics could mitigate this entirely as someone who was plotting surely ought to make sure they had the correct worksets open when exporting any information and if there was one called 'Schematics' and they were issuing schematics, they have done a serious mistake haven't they?
  • We actually have our own line-based detail items which we use for pipes, ducts etc - we don't use detail lines for anything, so we don't have the problem of converting detail lines to model lines - as a result, i didn't even know that you could. Also as an aside, using line based detail items for pipes and ducts allows us to put to actually put info into the detail items and use tags to pull that info off, rather than using text. Not sure if you've thought of this but might be a top tip for you.
  • Not sure where CAD files come into the workflow/workaround we are talking about - guess you mean that people are doing the schematics in AutoCAD then bringing them into the model for issuing - but your text won't scale and this breaks your own suggestion as far as i can tell. 
  • As above, i agree level deletion is something to worry about but surely there is 1 level per project which shouldn't ever get changed and the schematics could be modelled on that? I agree this is something to think about that you would not have to think about with Drafting views.
  • Deleting model elements shouldn't be an issue as long as you have a View template set up with no model elements visible. Again another thing you wouldn't need to do in Drafting views, but only needs doing a single time which would take all of 10 minutes and then added to the template and you're sweet!

My final response is as follows: How do you know it is a quick win to add this functionality to Drafting views? Unless you have programmed the plans and drafting views portion of Revit yourself, surely you can't possibly know how easy or difficult, quick or slow, adding scope boxes to drafting views can be. You shouldn't make such accusations without intimate knowledge of the process involved. It's definitely a win but it might not be quick or easy.




Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Technology Administrators

Autodesk Design & Make Report