In Revit, you can change the thickness of element's lines by choosing from a predefined list (1, 2, 3, 4...). For each line weight, you can define what each weight number corresponds to according to the scale. But when choosing colors, you can select between direct colors and predefined and non-customizable color books. My idea is to be able to create a kind of custom color book, just like with line weights works, so you could go to Manage/Additional settings pulldown/Custom Colors And you can create color1, color2, color3... and decide what each one corresponds to. So, if you select color 2 to a line style, a category in VG, etc., later in the project you could change what color 2 corresponds to, and it will change throughout the entire project at once. This way, it would be possible to create your own project color book, maintaining color consistency and allowing you to speed up the workflow when needed. Example: Imagine having to produce all the documentation for a competition and your boss decides that terracotta isn't the exact shade he wanted, and tells you to change it by half a shade. You have to go view template by view template, changing it and checking that nothing has been changed per element... vs. Manage/Additional settings/Custom Colors -> Change Color 1 Show More

When you delete a line item within the filters section of the schedule properties window, Revit will delete all the filters below the one you select.  I want Revit to retain those filters below the one I removed.  It currently does not allow this in 2026/2027 and older. Show More

Please add more information to the tags than just Elevation from Level. Level Name and Elevation are also missing. These values should be pulled directly from the Scheduled Level parameter. This information should be available in all tag types, including Multi-Category Tags. Show More

Schedules can be saved to a separate file as a standard project file. The idea is to enhance that functionality to save into a revit family file alternatively thus setting up a rudimentary annotation family, the labels inside of which would be determined by the setup of the schedule. Show More

Currently, the Reset to Crop command always resets Grid and Level extents to the Model Crop Region. Although the Annotation Crop Offset can be adjusted numerically, Datum Elements (Grids and Levels) completely ignore the Annotation Crop and always extend to the Model Crop Region. I understand that Datum Elements are intentionally associated with the Model Crop because they are not purely annotation elements. Autodesk Technical Support has already confirmed that this is the current intended behavior after consulting the internal team. However, this request is not asking to change how Datum Elements work. Instead, I am requesting an optional documentation workflow enhancement that would allow users to choose which crop boundary should be used when executing Reset to Crop. Suggested Implementation When using Reset to Crop, provide an additional option such as: Reset Datum Extents To: Model Crop (Current Behavior) Annotation Crop (New Option) or alternatively, add a View Property: Datum Extents Reference Model Crop Annotation Crop This would work in a similar way to how Grid Extents can already be switched between 2D and 3D. Why This Is Important Architectural documentation frequently relies on: Enlarged Plans Callout Views Dependent Views Detail Plans In these views, the Annotation Crop usually represents the desired drawing composition rather than the Model Crop. Currently, Grid and Level extents must be manually adjusted in nearly every enlarged view because Reset to Crop ignores the Annotation Crop. Providing this optional setting would: Reduce repetitive manual work Produce cleaner documentation Improve drawing presentation Speed up sheet preparation Improve BIM documentation workflows Most importantly, this enhancement would remain fully backward compatible, since the existing behavior could remain the default option. Testing Performed The current behavior has been verified in: Revit 2025 Revit 2026 Brand-new blank projects Floor Plans Callout Views 2D Grid Extents In every case, Reset to Crop always follows the Model Crop Region and never the Annotation Crop. Final Note This Idea is not requesting any change to the fundamental behavior of Datum Elements. It simply proposes an optional documentation feature that would allow users to decide whether Reset to Crop should reference the Model Crop or the Annotation Crop. This small enhancement would significantly improve documentation efficiency while preserving the existing Revit workflow for all current users. Thank you for considering this suggestion. Show More

Currently, the Break option in a Revit tag label only creates a new line when the parameter immediately following the break contains a value. When optional parameters are used, the line break may not work as intended. If the next parameter is empty, Revit skips it and continues to the next parameter containing a value. However, if that parameter does not have the Break option enabled, the content remains on the same line. The proposed enhancement is for the Break option to define the tag layout independently of whether the following parameter contains a value or not. When a break is enabled, the next parameter  should always start on a new line, even when one or more parameters between them are empty. This would make tag composition more predictable and allow tags containing optional parameters to maintain a consistent layout without requiring multiple tag families or complex workarounds. Show More

There should be back up of sheets from previous package of projects, so you can see what was published during DD or even post IFC without having to go through all of your files. these sheets can also highlight the changes that were made in the phases so you can easily identify where you need to place revision clouds. Show More

Current Behavior When a view is split using "Duplicate as a Dependent View," the parent and its dependent views currently share only model geometry. All annotations — dimensions, spot elevations, tags, and detail lines — are completely independent between the parent and each dependent view. This makes the parent-child relationship functionally similar to a simple "Duplicate," with the only practical difference being that dependents allow separate crop regions of the same view. Problem In real-world documentation workflows, teams frequently need to split one large floor plan across multiple sheets (for example, dividing a large building plan into left/right or quadrant sections). In these cases, there are typically: Core annotations that should appear consistently across the entire plan (main dimension strings, spot elevations, gridline callouts, key structural tags) Section-specific annotations that only apply to a particular portion of the plan (local detail callouts, finish notes, furniture tags) Currently, there is no way to place a "core" annotation once and have it automatically appear across all dependent views. Every dependent must be annotated manually and separately, and any revision to a shared annotation must be repeated by hand in every dependent view. This is time-consuming and creates a high risk of inconsistency between dependent views of the same building. Suggested Improvement Introduce a one-way, parent-to-child annotation inheritance for dependent views: Annotations placed in the parent view would automatically appear in all dependent views (within their respective crop regions). Annotations placed in a dependent view would remain local to that dependent only and would not propagate back to the parent or to sibling dependents. This one-directional relationship would preserve the logical hierarchy of "parent" and "child," giving the relationship real functional meaning beyond crop regions alone, while still allowing each dependent to carry its own unique, localized annotations. This behavior would mirror how revision clouds currently behave (shared across parent/dependents), but scoped specifically to one direction — from parent down to children — for standard annotation types like dimensions, spot elevations, and tags. Show More

表題の通り、マルチカテゴリの集計表ですべてのカテゴリを集計対象とする修正を希望します。   Show More

When publishing sheets from Revit to Autodesk Forma (ACC), there is currently no option to control the visibility of view crop boundaries. While Revit provides this functionality when printing sheets, the same setting is not available during cloud publishing.  Our team uses visible crop boundaries on interior elevations to outline the extents of each view. See sample image not showing crop boundary in published sheets.   Providing a way to either inherit the Print dialog settings or offer similar options within the publishing settings would help ensure consistency between printed and published documentation.   Show More

Issue: When a revision is manually added through Revisions on Sheet, it should appear in the sheet’s Latest Revision / revision date field even when the revision Cloud and Tag are hidden. Current behavior appears inconsistent when Cloud and Tag visibility is turned off. The revision can be added to the sheet, but the sheet schedule does not always report it as the latest revision. Use case: For issued drawing sets, we need sheets to show an issue entry such as: Revision Schedule: No.| Date | Description __ | 2026-06-29 | Issued for Permit without requiring a visible revision sequence number, cloud, or tag. The sheet list should still report the latest issue date, for example: Sheet Schedule: Sht. | Name | Latest Revision AE101 | First Floor Plan | 2026-06-29 Using an Alt+030 blank revision sequence appears to work, but Revisions on Sheet should be enough to drive the sheet’s latest revision data. Show More

It would be very helpful to be able to define the sheet number based on multiple parameters. In many projects, the actual sheet number is composed of several different parameters. Currently, if you also want to find the correct sheet in the sheet list, you have to manually enter the full sheet number for each sheet. This is unnecessary and only creates potential for typing and transfer errors. Show More

The ability to show view names in callout tags. Just like section tags. Show More

Temporary View Properties (TVP) must not rotate or move the crop region at all.   In dependent views with rotated crops, enabling TVP can incorrectly shift or reset the crop region and it may not restore correctly after exiting.   This breaks dependent view stability and documentation consistency.   Forum reference (similar behavior reported): https://forums.autodesk.com/t5/revit-structure-forum/crop-region-behavior-with-view-template-applied-from-enable/td-p/9766116   Workarounds: Converting the dependent view to an independent view resolves the issue, and assigning a scope box also prevents it; however, both approaches are not always practical or applicable in real project workflows.   Show More

In construction projects, work progress is typically broken down into highly detailed stages. In our workflow, these stages are represented as phases in Revit. However, in practice, multiple detailed phases often belong to a larger construction stage or work package. As projects become more complex, especially in underground station construction, the number of phases can become very large, making phase selection and filtering increasingly difficult and time-consuming. Therefore, the idea is to introduce a Phase Group feature in Revit. This would allow multiple phases to be organized under a higher-level group. Users could then select, filter, and manage phase groups instead of individually handling dozens of detailed phases. Such a feature would improve usability, reduce the complexity of phase management, and enhance productivity on large-scale projects with extensive construction sequencing requirements, such as underground stations and other major infrastructure projects. Show More

Hi! We use the "Visible in Option" parameter frequently for our setups and showing correct documentation per view. However, this parameter only applies to Floor Plans, Sections, but not Elevations. It would be fantastic if this view applied to all types of views.   Thanks for the consideration! Show More

I am going through our custom RFAs and would like to get a schedule of elements within the RFA that is only visible within the Revit Family Editor.   This will help with standardizing the build and nomenclature of the RFA elements.   Hope this is a possibility. Show More

r2025.4_Give the colour scheme dialog an export or save as button. Some of these similar looking windows already have them so you would not even have to reinvent the icon wheel. Show More

The new Numbering options in Revit 2027 are great, but the current workflow to remove numbering gaps is:   Click the Manage tab (Alt G) Click the Numbering pushbutton (AN) Select Template (each element individually) Click Number Sequence Set the starting value for each partition Click Remove Gaps   It would be nice if there were an option to enable "Auto-Remove Gaps" as you delete and recreate elements, so that you don't have to go through the above workflow at the end of each modelling session. I currently have a PyRevit script that runs the workflow for me, but I feel this function should be part of Revit.     Show More