Autodesk Revit Quiz: View Filters
10 questions · exam conditions
0:00
View FiltersQuestion 1 of 10

The project filter Fire-Rated Doors is applied to three plans. Each plan uses different line colors for matching doors. A user edits the project filter rule from Fire Rating is greater than or equal to 60 minutes to Fire Rating is greater than or equal to 90 minutes.

What is the expected result in the three plans?

Each plan evaluates the new 90-minute rule while retaining its own filter graphic overrides
Only the active plan evaluates the new rule because filter criteria are stored per view
Each plan adopts the active plan's line color because the rule and overrides are stored together
The filter is removed from all three plans and must be added again after editing
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: View Filters

Practice View Filters in Autodesk Revit with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on View Filters, giving you a quick way to practice the rules, question types, and explanations that matter most for Autodesk Revit.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

The project filter Fire-Rated Doors is applied to three plans. Each plan uses different line colors for matching doors. A user edits the project filter rule from Fire Rating is greater than or equal to 60 minutes to Fire Rating is greater than or equal to 90 minutes.

What is the expected result in the three plans?

  1. Each plan evaluates the new 90-minute rule while retaining its own filter graphic overrides (correct answer)
  2. Only the active plan evaluates the new rule because filter criteria are stored per view
  3. Each plan adopts the active plan's line color because the rule and overrides are stored together
  4. The filter is removed from all three plans and must be added again after editing
Explanation: When working with Revit project filters, it helps to understand that two things are stored separately: the filter rules (the criteria, like "Fire Rating ≥ 90 minutes") and the graphic overrides (colors, line weights, patterns) applied per view. This separation is the key concept being tested here. Project filters in Revit are defined once at the project level, meaning every view that uses the filter shares the same rule logic. When you edit the filter rule — changing the threshold from 60 to 90 minutes — that change propagates automatically to every view where the filter is applied. However, each view independently stores its own graphic overrides for that filter. So one plan can show matching doors in red, another in blue, and a third in green — and editing the rule doesn't touch any of those view-specific settings. This confirms that A is correct: all three plans evaluate the updated 90-minute rule while each retains its own line color overrides. B is wrong because filter criteria are not stored per view — they're stored at the project level and shared across all views using the filter. C describes a behavior that doesn't exist in Revit; graphic overrides are always view-specific and are never "adopted" from another view when a rule is edited. D is incorrect because editing a filter rule doesn't remove the filter from any view — the filter remains applied, simply using the updated criteria. A useful pattern to remember: in Revit, what to filter is project-level, but how it looks is view-level. Keep those two layers distinct in your mind when answering filter-related questions.

Question 2

A door filter highlights doors whose type parameter Acoustic Rating equals 45 min. Six doors use Type A, which currently has an Acoustic Rating of 45 min. A user edits the Acoustic Rating value in Type A's type properties to 60 min without duplicating the type.

What happens when the view regenerates?

  1. Only the selected door stops matching because filters evaluate type parameters as instance values
  2. All six Type A doors stop matching because the edited type parameter applies to every instance (correct answer)
  3. All six doors continue matching until the filter is removed and reapplied to the view
  4. Only newly placed Type A doors use 60 min; existing instances retain the previous value
Explanation: Whenever you see a Revit question about type parameters and filters, the critical concept to keep in mind is the distinction between type parameters and instance parameters — and how that distinction affects every door, wall, or element sharing that type. In Revit, a type parameter belongs to the family type itself, not to any individual placed instance. This means every element that uses Type A shares the exact same type parameter values. When the user changes the Acoustic Rating from 45 min to 60 min directly on Type A — without duplicating it first — that change propagates instantly to all six doors using that type. When the view regenerates, the filter evaluates each door's Acoustic Rating, finds 60 min instead of 45 min, and none of the six doors satisfy the filter condition anymore. Answer B is correct. Answer A is wrong because it describes type parameters behaving like instance parameters, where individual doors could hold independent values. That's not how Revit works — type parameters are shared across all instances of that type. Answer C is wrong because filters in Revit update dynamically during view regeneration; they don't require manual removal and reapplication to reflect current parameter values. Answer D describes how instance parameters behave — each placed element could theoretically hold a different value — but type parameters have no per-instance memory of previous values. A useful rule of thumb: if a question mentions editing a value "in type properties" without duplicating, assume every instance of that type is affected simultaneously. This is one of the most common traps on the Revit exam, so always ask yourself — is this a type or instance parameter?

Question 3

A rule-based filter applies a red surface pattern to structural framing whose Mark begins with RF. A beam satisfies the rule, its category is enabled, and the filter is enabled in the view. However, the beam lies entirely above the plan's view range and is not otherwise displayed.

Which action is required for the red filtered beam to appear in this plan?

  1. Increase the filter's transparency so geometry outside the view range becomes visible
  2. Adjust the view range so the beam is displayed, while retaining the filter override (correct answer)
  3. Move the filter to the top of the Filters list so it overrides the view range
  4. Change the filter from a surface override to a cut-pattern override only
Explanation: Whenever you see a Revit question involving filters and visibility, remember that filters only affect elements that are already visible in the view — they cannot override the fundamental display rules that determine whether an element appears at all. In Revit, a plan view's View Range (defined by Top, Cut Plane, Bottom, and View Depth) controls which elements are displayed. If a beam sits entirely above the Top clip of the view range, it simply doesn't exist in that view's display — no filter, override, or style setting can make an invisible element visible. The filter's red surface pattern is a graphic override, not a visibility toggle that bypasses geometric clipping. Once you adjust the view range so the beam falls within the displayable region, the filter override will apply automatically, since the beam already satisfies the rule. That makes B the correct action. A is wrong because filter transparency is a graphic property affecting how a visible element looks — it has no ability to bring geometry outside the view range into the display. C is a misconception about how the Filters list works; filter order only resolves conflicts between competing overrides on already-visible elements, not between filters and view range logic. D misunderstands the issue entirely — switching from a surface override to a cut-pattern override changes the type of graphic replacement but still cannot display an element excluded by the view range. As a study tip: always separate "is the element displayed?" (governed by View Range, Workset visibility, Category on/off) from "how does the element look?" (governed by filters and overrides). Filters operate at the second level, never the first.

Question 4

A filter for Mechanical Equipment uses the rule Maintenance Status equals Remove. In a coordination plan, the filter's Visibility option is cleared so matching equipment is hidden. An otherwise visible air-handling unit currently has Maintenance Status set to Remove.

What happens if the unit's Maintenance Status is changed to Retain?

  1. It remains hidden until the view is closed because visibility filters do not reevaluate automatically
  2. It becomes visible because it no longer matches the filter whose Visibility option is cleared (correct answer)
  3. It remains hidden because clearing Visibility permanently hides each element that once matched
  4. It becomes visible only after the Remove filter is deleted from the entire project
Explanation: When working with Visibility/Graphics filters in Revit, it helps to understand that filters are dynamic rules, not permanent stamps. A filter evaluates each element's parameter values in real time — every time the view renders, Revit checks whether each element currently matches the filter's criteria. In this scenario, the filter hides any Mechanical Equipment where Maintenance Status equals "Remove." The air-handling unit matches that rule, so it's hidden. But the moment you change the unit's Maintenance Status to "Retain," it no longer satisfies the filter condition. Since the filter has nothing to act on, the unit falls back to its normal category visibility — and because it's otherwise visible, it reappears immediately. That's exactly what answer B describes, making it correct. Answer A is wrong because it invents a behavior that doesn't exist — filters don't require a view to be closed and reopened to reevaluate. Revit updates visibility dynamically as parameters change. Answer C describes a "permanent hide" concept that confuses filter-based visibility with the Hide Element command. Clearing the Visibility checkbox in a filter hides elements while they match; it's not a one-time branding. Answer D is incorrect because the filter's existence in the project is irrelevant — what matters is whether the element matches the filter's rule, not whether the filter itself is deleted. A useful study tip: always distinguish between filter-based visibility (conditional, dynamic, parameter-driven) and element-level overrides like Hide in View (manual, persistent). Revit exam questions frequently test whether you understand that filters respond to live data, not cached states.

Question 5

In a floor plan, walls matching a parameter filter are cut by the view's cut plane. The filter sets Projection Lines to green and a heavier weight, but Cut Lines remains unchanged. The matching walls continue to display their cut edges with the original line graphics.

What should be changed to emphasize the visible wall edges in this plan?

  1. Clear the filter's Visibility option and enable halftone for the Walls category
  2. Set the filter's Projection Surface Pattern to the required color and weight
  3. Lower the plan's cut plane so every matching wall is shown in projection
  4. Set the filter's Cut Lines override to the required color and line weight (correct answer)
Explanation: Whenever you see a question about Visibility/Graphics overrides and filters in Revit, you need to distinguish between two separate contexts: Projection (what you see beyond the cut plane) and Cut (what is sliced by the cut plane). Filters apply overrides in both contexts independently, and choosing the wrong one is the most common mistake. In this scenario, the walls are being cut by the view's cut plane — meaning their visible edges are controlled by the Cut Lines override, not the Projection Lines override. The filter was configured with Projection Lines set to green and heavier weight, but since the walls appear in cut (not projection), those projection settings have no effect on the cut edges. To emphasize the wall edges as they appear in the plan, you must set the Cut Lines override within the filter to the desired color and line weight. That makes D the correct approach. A is wrong because clearing the filter's Visibility option would hide the walls entirely, and enabling halftone would actually de-emphasize them — the opposite of the goal. B is wrong because Surface Pattern controls fill patterns on faces, not edge line graphics; it won't affect how the cut edges appear. C is a common misconception: lowering the cut plane might cause walls to appear in projection rather than cut, but this changes the view setup rather than the filter override, and it would affect all walls in the view — not just the filtered ones. As a study tip: always ask yourself whether elements are appearing in cut or projection before applying a filter override. Revit treats them as entirely separate graphic channels.

Question 6

A quality-control view must highlight doors for which the text parameter Approval Code has never been assigned. Doors containing Approved, Pending, or any other entered text must not match the filter.

Which rule most precisely identifies the required doors?

  1. Approval Code does not equal Approved
  2. Approval Code does not contain Pending
  3. Approval Code has no value (correct answer)
  4. Approval Code equals a blank space character
Explanation: When building filters in Revit, it's critical to distinguish between a parameter that holds no value at all and one that simply doesn't match a specific string. This question tests exactly that distinction. The goal is to catch doors where the Approval Code parameter was never touched — it's completely empty, not just missing a particular word. The rule that captures this precisely is C: Approval Code has no value. In Revit's filter logic, "has no value" targets parameters that are genuinely null — never assigned anything. This is the only rule that reliably excludes every door with any entered text while including only the truly blank ones. Here's why the other options fall short. A ("does not equal Approved") would flag doors with "Pending," blank fields, and any other non-"Approved" text — far too broad. It would incorrectly include doors that have been assigned a value other than "Approved." B ("does not contain Pending") has the same problem in reverse: it would match doors with "Approved" or any other non-"Pending" value, completely missing the intent. D ("equals a blank space character") is a common trap — a space character is actually a value. A parameter containing a single space would pass this filter, but a truly empty parameter would not, making it both unreliable and imprecise. As a study tip, whenever a Revit filter question involves "never assigned" or "empty" parameters, look for "has no value" rather than any comparison against an empty string or a specific word. Null and blank are not the same thing in Revit's filter engine.

Question 7

A user creates a selection filter containing all plumbing fixtures currently marked with the instance parameter Inspection Status equal to Failed. Later, additional fixtures are changed to Failed, but they do not receive the filter's red override.

Which workflow will make future Failed fixtures receive the override automatically?

  1. Continue using the selection filter and enable automatic membership in Visibility/Graphics
  2. Group the failed fixtures and apply the selection filter to the completed model group
  3. Convert Inspection Status to a type parameter and retain the existing selection filter
  4. Create a rule-based Plumbing Fixtures filter using Inspection Status equals Failed (correct answer)
Explanation: When working with Revit filters, the critical distinction to understand is the difference between selection filters and rule-based filters. Selection filters capture a static snapshot of whatever elements you manually select at a specific moment — they don't update dynamically as project conditions change. Rule-based filters, by contrast, continuously evaluate elements against defined criteria, so any element meeting the rules is automatically included, now and in the future. This is exactly why D is correct. By creating a rule-based Plumbing Fixtures filter with the condition "Inspection Status equals Failed," Revit will automatically apply the associated Visibility/Graphics override to any fixture that carries that parameter value — including ones added or updated after the filter was created. The filter logic runs live against the model. A is a trap because selection filters have no "automatic membership" toggle in Visibility/Graphics. Once created, their membership is frozen to the original selection. No such setting exists. B misunderstands how model groups and filters interact. Applying a selection filter to a group doesn't grant dynamic override behavior — groups are organizational tools, not a mechanism for automatic filter membership. C sounds plausible but misses the root problem. Converting Inspection Status to a type parameter changes where the parameter lives (on the type rather than the instance), but a selection filter still won't update automatically regardless. The static nature of selection filters remains the bottleneck. As a study tip, whenever a Revit question involves overrides that should respond automatically to changing conditions, think rule-based filters — they're the only filter type in Revit that evaluates membership dynamically.

Question 8

A facilities team wants a plan view to highlight mechanical equipment when either of these conditions is true: the Asset Status is Replace, or the Asset Status is Review and the Criticality is High. Equipment marked Review with Medium criticality must not be highlighted.

Which rule structure should be used in the rule-based view filter?

  1. Asset Status is Replace AND Asset Status is Review AND Criticality is High
  2. Asset Status is Replace OR Asset Status is Review OR Criticality is High
  3. Asset Status is Replace OR a nested AND group for Review and High criticality (correct answer)
  4. A nested OR group for Replace and Review, AND Criticality is High
Explanation: When building rule-based view filters in Revit, you need to translate plain-language conditions into precise logical structures. The key is identifying which conditions use AND (both must be true) versus OR (either can be true), especially when conditions are mixed. The scenario requires highlighting equipment when: Replace is true, or when Review AND High criticality are both true. This is a classic "compound OR with a nested AND" structure. Answer C correctly captures this: a top-level OR between the Replace condition and a nested AND group that requires both Review and High criticality simultaneously. This means Replace-only equipment is highlighted, Review+High equipment is highlighted, but Review+Medium equipment is excluded — exactly what the team wants. Answer A uses AND throughout, meaning all three conditions must be true at once. No real piece of equipment could simultaneously have a status of both Replace and Review, so this filter would return nothing useful. Answer B uses OR for every condition, which is too permissive — Review+Medium equipment would be highlighted because "Asset Status is Review" alone would trigger a match, violating the requirement. Answer D groups Replace and Review under a nested OR, then ANDs that with High criticality. This would require High criticality for all highlighted items, meaning Replace-status equipment without High criticality would be excluded — another misread of the scenario. When you see filter logic questions, map each condition to a truth table mentally: write out which combinations should pass and which should fail, then work backward to the structure. Mixed OR/AND scenarios almost always require nesting, and that's your signal to look for answer C-style options.

Question 9

A floor plan has the view template Life Safety Plan assigned. The template controls the Filters setting. In Visibility/Graphics, the filter list and its graphic overrides cannot be edited for that plan. Other properties not controlled by the template remain editable.

How should the user change the filter graphics for every view using this template?

  1. Edit the filter overrides in the Life Safety Plan view template (correct answer)
  2. Edit Visibility/Graphics in the plan after enabling Reveal Hidden Elements
  3. Rename the project filter and recreate its rules in the active plan
  4. Apply a temporary view property and then save it to all dependent views
Explanation: When working with view templates in Revit, the core principle to understand is this: any property controlled by a view template can only be changed from within the template itself — the individual view becomes locked for that setting. This question tests whether you understand that relationship and know where to go when a template-controlled property needs updating across multiple views. Since the Life Safety Plan template controls the Filters setting, the filter graphics are frozen in every view using that template. The correct approach is A — edit the filter overrides directly inside the Life Safety Plan view template. When you do this, the change propagates automatically to every view assigned to that template, which is precisely the efficiency view templates are designed to provide. B is a trap that confuses two separate tools. Reveal Hidden Elements helps you see elements hidden by Hide/Isolate commands — it has no effect on properties locked by a view template. You still cannot edit template-controlled settings in the view itself. C describes a destructive workaround that doesn't solve the problem. Renaming a filter and recreating its rules in a single plan would break the relationship with other views and doesn't address the template lock at all. D misapplies the concept of temporary view properties. Temporary overrides are for quick, non-permanent display changes — they cannot be "saved to dependent views," and they don't override template-controlled properties anyway. The study tip here: whenever a Visibility/Graphics setting is grayed out in a view, your first instinct should be to check whether a view template is controlling it — and if so, go to the template, not the view.

Question 10

A project parameter named Warranty Status is bound only to the Doors category. A coordinator attempts to create one rule-based filter containing both Doors and Windows, with the rule Warranty Status equals Expired. Warranty Status is unavailable as a filter rule parameter.

What is the most appropriate change if one filter must evaluate both categories?

  1. Bind Warranty Status to Windows as well, and then use it in the multicategory filter (correct answer)
  2. Add the filter to a view first, and then select Warranty Status from the view properties
  3. Create the filter for Doors, and add Windows after the Warranty Status rule is completed
  4. Convert Warranty Status to a type parameter so it becomes available to every model category
Explanation: When working with rule-based filters in Revit, a critical constraint governs multicategory filters: every parameter used as a filter rule must be shared across all selected categories. If even one category lacks the parameter, Revit won't allow it as a rule criterion. This is the core concept being tested here. Since Warranty Status is only bound to Doors, adding Windows to the same filter makes the parameter unavailable — Revit can't evaluate a field that Windows elements don't possess. The fix is straightforward: bind Warranty Status to the Windows category as well (via Project Parameters in Manage tab), and then both categories share the parameter, making it valid for a multicategory filter rule. That's exactly what A prescribes, making it the correct answer. B is a trap — adding a filter to a view first doesn't change which parameters are accessible as rule criteria. View properties don't unlock parameters that aren't bound to all filter categories. C suggests building the filter for Doors alone and adding Windows after the rule is set. Revit doesn't allow this workaround; once Windows is added as a category, it immediately invalidates a rule using a parameter not bound to it. You can't "lock in" the rule before expanding categories. D sounds plausible but misidentifies the problem. Converting to a type parameter changes how the value is stored (per type vs. per instance), not which categories have access to it. Category binding is the real issue, not parameter type. Study tip: On filter-related questions, always ask yourself: "Does every selected category share this parameter?" If not, the filter rule won't work — fix the binding first.