Autodesk Revit Quiz: Shared Parameters
10 questions · exam conditions
0:00
Shared ParametersQuestion 1 of 10

Two consultants independently create Text shared parameters named Equipment ID. One definition is added to mechanical equipment families, while the other is added to an equipment tag. The spelling, capitalization, and data type are identical, but the definitions were created separately.

What is the most likely result when the tag is used?

The tag will read the value because Revit matches shared parameters by visible name and data type.
The tag will not read the value because the two definitions have different unique identifiers.
The tag will read the value only after both definitions are placed in the same parameter group.
The tag will not read the value until both parameters are changed from Text to Multiline Text.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Shared Parameters

Practice Shared Parameters 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 Shared Parameters, 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

Two consultants independently create Text shared parameters named Equipment ID. One definition is added to mechanical equipment families, while the other is added to an equipment tag. The spelling, capitalization, and data type are identical, but the definitions were created separately.

What is the most likely result when the tag is used?

  1. The tag will read the value because Revit matches shared parameters by visible name and data type.
  2. The tag will not read the value because the two definitions have different unique identifiers. (correct answer)
  3. The tag will read the value only after both definitions are placed in the same parameter group.
  4. The tag will not read the value until both parameters are changed from Text to Multiline Text.
Explanation: Whenever you see a question about shared parameters in Revit, the critical concept to understand is how Revit identifies parameters — not by their name, but by a hidden GUID (Globally Unique Identifier) embedded in the shared parameter file at the moment of creation. Even though both "Equipment ID" definitions look identical — same spelling, same capitalization, same Text data type — they were created in two separate shared parameter files, meaning each received a different GUID. Revit uses this GUID to match a tag's label to the corresponding instance parameter on a family. Since the GUIDs don't match, the tag has no way to recognize the mechanical equipment's parameter as its own, and the value will simply not display. That makes B the correct answer. A is wrong because Revit does not match shared parameters by visible name and data type alone — if it did, any two parameters with the same name could accidentally link, which would break data integrity across large projects. C is wrong because parameter groups control organization in the Properties palette; they have no effect on whether a tag can read a parameter value. D is wrong because the Text vs. Multiline Text distinction is irrelevant here — the real problem is the GUID mismatch, not the data type. The study tip to remember: shared parameters are only truly "shared" when they come from the same entry in the same shared parameter file. If two teams need a parameter to communicate between a family and a tag, they must distribute and use the exact same .txt shared parameter file — no exceptions.

Question 2

A casework family already contains a non-shared family parameter named Finish Code. It is used in formulas and contains type-specific values. The parameter must now be displayed by a casework tag without changing the intended type-based behavior.

Which workflow is most appropriate?

  1. Rename the existing parameter, because a matching name automatically allows a tag label to access it.
  2. Bind a new instance project parameter and expect it to inherit the family's existing type values and formulas.
  3. Create a type shared parameter, transfer the values, update formula references, and use the same definition in the tag. (correct answer)
  4. Create ordinary text in the tag, then associate that text with the existing non-shared family parameter.
Explanation: Whenever Revit questions involve making a family parameter visible in a tag, the critical concept to understand is shared parameters. Tags in Revit can only display values from shared parameters — not ordinary family parameters, not project parameters. This is because shared parameters exist in an external definition file, allowing both the family and the tag family to reference the exact same parameter identity. The existing Finish Code parameter is non-shared, meaning the tag has no way to "see" it. To solve this correctly, you must convert it to a shared parameter. Workflow C does exactly that: you create a type shared parameter (preserving type-based behavior), migrate the existing values, update any formula references within the family to point to the new parameter, and load that same shared parameter definition into the tag as a label. This keeps type-specific behavior intact while making the parameter tag-accessible. Option A is a trap — renaming a non-shared parameter does nothing to make it available to a tag. Name matching is irrelevant; what matters is parameter identity stored in the shared parameter file. Option B fails for two reasons: project parameters cannot be read by tags at all, and instance parameters would break the type-based behavior the team relies on. Option D is impossible by design — Revit does not allow tag text elements to be associated with non-shared family parameters; the association mechanism simply doesn't exist for that parameter type. Your key study tip: memorize this rule — tags can only label shared parameters. Any question asking how to display a family value in a tag will always lead back to shared parameters as the required solution.

Question 3

A shared parameter named Clearance was created with a Text data type and added to several prototype families. The design team later decides that Clearance must drive a family dimension and display project units correctly.

What should the family author do?

  1. Keep the Text definition and associate it directly with the dimension after entering values such as 900 mm.
  2. Change the parameter group from Identity Data to Dimensions so Revit treats the existing definition as a length.
  3. Create a new Length shared parameter definition and replace or reassociate the prototype parameters with it. (correct answer)
  4. Keep the Text definition and add a length formula that automatically converts every entered string into dimensional data.
Explanation: Whenever you see a question about shared parameters in Revit families, the key concept to remember is that a shared parameter's data type is permanently fixed at creation. The data type isn't a display setting or a grouping preference — it's a fundamental definition stored in the shared parameter file that cannot be retroactively changed. Because the original Clearance parameter was defined as Text, it can only store string values. Text parameters cannot be associated with dimensions, cannot respond to project units, and cannot drive geometry in a family. No amount of configuration inside the family or project will change this behavior. The only correct path forward is to create a brand-new shared parameter definition using the Length data type, then replace or reassociate that new definition wherever Clearance was previously used. This is answer C, and it's correct because it addresses the root cause: the wrong data type was chosen at creation. A is wrong because Revit simply will not allow a Text parameter to be associated with a dimension — the option won't appear. Typing "900 mm" as a string doesn't make it dimensional data. B is a common misconception. The parameter group (such as Identity Data vs. Dimensions) only controls where the parameter appears in the Properties palette for organizational clarity. It has absolutely no effect on data type or unit behavior. D is impossible. Revit families don't support formulas that convert Text values into length data — formula fields require numeric or compatible types as inputs. The study tip here: whenever you see a Revit parameter behaving unexpectedly, check the data type first. It's the one thing you cannot fix without rebuilding the definition.

Question 4

A manufacturer wants a Product Series value stored in a family so it follows the family into every project. All placed instances of a given family type must show the same Product Series value, and the value must be available to schedules and tags.

How should Product Series be configured?

  1. Create it as an instance family parameter and enter the same value manually for every placed component.
  2. Create it as a type shared parameter in the family and use the same definition in the tag. (correct answer)
  3. Create it as an instance shared project parameter bound separately in each destination project.
  4. Create it as a type family parameter and place matching static text in the associated tag.
Explanation: When a question asks about storing manufacturer data in a family so it travels with that family everywhere and works with both schedules and tags, you need to think about three intersecting Revit concepts: parameter scope (type vs. instance), parameter portability (family vs. shared), and tag compatibility. A type parameter means every placed instance of the same family type shares one value automatically — no manual re-entry required. A shared parameter is defined in an external .txt file, giving it a stable GUID that both families and projects can reference, which is the only way a tag family can read the same parameter that the host family exposes. Combining these two qualities — type scope and shared definition — is exactly what Option B does. Because the parameter lives at the type level inside the family file, it travels into any project the family is loaded into, all instances stay consistent, and the tag can bind to the same shared parameter definition to display it. Option A fails on two counts: instance parameters require the same value to be typed into every single placed component, and a regular (non-shared) family parameter cannot be read by a tag family. Option C places the parameter as a project parameter, which means it doesn't live inside the family itself — it must be manually re-added to each new project and cannot be used in tags at all. Option D uses a type family parameter, which handles the consistency piece, but a non-shared family parameter is invisible to tag families; the "matching static text" workaround is hardcoded, not data-driven. Remember this pattern: shared = schedulable + taggable + portable; type = consistent across all instances. Any question requiring all three behaviors points directly to a type shared parameter.

Question 5

A lighting fixture family contains a shared parameter named Emergency Circuit ID. A lighting fixture tag is created, but the parameter does not appear among the label parameters available in the tag family.

Which action most directly resolves the issue?

  1. Add the same Emergency Circuit ID shared definition to the tag label, using its existing shared parameter identity. (correct answer)
  2. Create a new tag-family parameter with the same name and assign it the same instance-or-type setting.
  3. Place the fixture family inside the tag family so the tag can read its Family Types dialog directly.
  4. Add ordinary text named Emergency Circuit ID and associate it with the tagged element after placement.
Explanation: Whenever you see a question about tags not displaying parameters, focus on how Revit tags communicate with hosted elements. Tags don't automatically inherit parameters from the families they label — instead, a tag family must explicitly reference the same shared parameter definition (identified by its unique GUID) to read and display that parameter's value. This is exactly why A is correct. Shared parameters are defined by a globally unique identifier stored in a shared parameter file. When you add that same shared parameter definition to the tag family's label, Revit recognizes the matching GUID and knows to pull the value from the tagged element. The tag and the fixture family are speaking the same language because they reference the identical parameter identity — not just a name, but the underlying GUID. B is tempting because it sounds logical, but creating a brand-new tag-family parameter — even with the exact same name and instance/type setting — generates a different GUID. Revit uses the GUID, not the name, to match parameters between families. This new parameter would have no connection to the fixture's Emergency Circuit ID data. C misunderstands how tag families work entirely. Tags read parameter values through the tagging relationship established at placement; you never nest the host family inside the tag family to achieve this. That would corrupt the tag's purpose and functionality. D confuses static text with a live parameter label. Ordinary text in a tag family is hardcoded — it cannot dynamically pull values from a tagged element. Study tip: Whenever shared parameters are involved across families, remember: the GUID is the true identity, not the name. If tags can't see a parameter, the shared definition needs to be added directly to the tag family.

Question 6

A furniture schedule includes chairs from two independently authored families. Family X contains the approved shared parameter Warranty Class. Family Y contains an ordinary family parameter also named Warranty Class. The schedule field based on the approved shared definition reports values for Family X but not for Family Y.

What is the most appropriate correction for Family Y?

  1. Rename its ordinary parameter to exactly match the capitalization used in the schedule field.
  2. Create a second schedule field for the ordinary parameter and combine the fields by matching their names.
  3. Change its ordinary parameter to the same parameter group used by Family X and reload it.
  4. Add the approved shared definition to Family Y and transfer the existing values to that parameter. (correct answer)
Explanation: Whenever you see a question about schedule fields not reporting values across multiple families, think about shared parameters versus ordinary family parameters. A schedule field bound to a shared parameter definition is identified by a unique GUID — not just a name. Revit uses that GUID to match values across families, regardless of what the parameter is called on screen. Family X works correctly because its parameter is built from the approved shared definition (same GUID). Family Y has an ordinary parameter that merely shares the same name — Revit sees it as a completely different parameter and cannot populate the same schedule field with its values. The only real fix is option D: open Family Y in the Family Editor, add the approved shared parameter from the shared parameter file, then transfer or re-enter the existing values into that new parameter before reloading the family. Once Family Y's parameter carries the same GUID, the schedule field will recognize and display its values automatically. A is wrong because capitalization is irrelevant — Revit's matching is GUID-based, not name-based. Renaming or retyping the parameter name changes nothing about how Revit resolves it in a schedule. B is wrong because you cannot merge two independently defined parameters into a single schedule field just by giving them the same column name. They remain distinct parameters and will populate separate columns. C is wrong because the parameter group (dimensions, identity data, etc.) controls where the parameter appears in the Properties palette, not whether it shares a definition with another family's parameter. Changing the group does nothing to unify the two parameters. As a study tip: whenever a Revit schedule fails to display values for some families, your first question should always be "Is the same shared parameter — same GUID — used in every contributing family?"

Question 7

A shared parameter file was used to add Service Zone to several families and to a matching tag. The file is later moved to an unavailable network location, but the completed families and tag have already been loaded into a project.

Which statement best describes the immediate effect?

  1. Existing values and tag labels stop working because every shared parameter is read live from the external file.
  2. Existing families and tags continue working, but selecting that definition for new content requires access to an appropriate shared parameter file. (correct answer)
  3. Existing values remain schedulable, but every tag label is converted automatically to ordinary text until the file returns.
  4. Existing parameters become ordinary family parameters, although recreating the same name later restores their shared status.
Explanation: When you see a question about shared parameters in Revit, think about the distinction between definition and data. A shared parameter file (.txt) is essentially a lookup registry — it's consulted when you want to assign or identify a shared parameter definition for new content. The actual parameter values and their behavior inside loaded families and projects are stored within those files themselves, not live-streamed from the external text file. This is why B is correct. Once families containing "Service Zone" are loaded into a project, that parameter's GUID-based identity, its values, and its tag mapping all live inside the project and family files. Moving or losing the shared parameter file doesn't erase any of that. However, if you later want to add that same shared parameter to a new family, or verify its definition against another file, you'll need access to a compatible shared parameter file. A is wrong because it describes a streaming model that doesn't exist in Revit — shared parameters are not read live from the external file during project operation. C incorrectly suggests that tag labels degrade to plain text without the file; tags work because the parameter GUID is embedded in both the family and the tag, not because the external file is present. D is wrong in two ways: parameters don't silently convert to ordinary parameters, and recreating a parameter with the same name but a different GUID would actually create a mismatched, non-shared definition. A useful study tip: remember that the shared parameter file is a registration tool, not a runtime dependency. Questions that imply real-time reliance on that file are always describing behavior Revit doesn't actually perform.

Question 8

A window family uses an existing non-shared Sill Extension parameter to label a reference-plane dimension and to calculate another value with a formula. The firm now requires Sill Extension to be available in a window tag and in standardized schedules across multiple projects.

Which sequence provides the most reliable conversion?

  1. Create a Length shared parameter, relabel the dimension to reference it, update the formula to reference the new parameter, verify transferred values, and add the same shared definition to the tag. (correct answer)
  2. Create a Text shared parameter, copy the displayed dimension strings into it as stored values, keep the original length formula referencing the old parameter, and add the text definition as a label in the tag.
  3. Rename the original family parameter to match the required schedule column heading, export a window schedule to confirm the field appears, and create a tag label parameter using the same visible name.
  4. Create a Length project parameter bound to windows in each destination project, leave the family dimension constraints and formulas unchanged, and expect the tag label to derive its values from the original family parameter.
Explanation: Whenever you see a question about sharing family parameters across tags and schedules in Revit, think about the fundamental distinction between family parameters, shared parameters, and project parameters — they serve different scopes and capabilities. Shared parameters are the only parameter type that can simultaneously drive geometry/formulas inside a family and appear in tags and schedules across multiple projects, because they're defined by a shared parameter file that any project or family can reference. To convert an existing non-shared parameter, you must replace it entirely: create a new Length shared parameter (matching the original data type), relabel the dimension to point to it, update any formulas to reference the new parameter, verify that values transferred correctly, and add that same shared definition to the tag family as a label. This is exactly what A describes — a careful, complete migration that preserves data type integrity and formula functionality. B fails on multiple levels: using a Text type for a dimension value breaks formula compatibility (you can't do math on text), and copying displayed strings means you lose the parametric relationship entirely. C is a common misconception — renaming a non-shared parameter does not make it shared. A parameter's name and its shareability are completely independent. Schedules across projects won't link on name alone. D confuses project parameters with shared parameters. Project parameters can appear in schedules but cannot be used as tag labels, and they don't integrate with family-level formulas or dimensions. Remember: if a parameter needs to work in a tag, it must be a shared parameter defined inside the family. That's the non-negotiable rule on this exam.

Question 9

A sensor family has a shared parameter named Sensor ID and is nested inside an air-handling-unit family. After the host family is loaded, the project team expects each nested sensor to appear as a separate schedulable and taggable component. Sensor ID is configured correctly, but the nested sensors are not recognized as separate project elements.

Which additional family setting is required?

  1. Set Sensor ID to a type parameter so every nested sensor becomes independently selectable in the project.
  2. Mark only the host air-handling-unit family as Shared so all nested content inherits separate identity.
  3. Move Sensor ID to the Identity Data group so Revit promotes each nested sensor into the project.
  4. Mark the nested sensor family as Shared, then reload it into the host and reload the host. (correct answer)
Explanation: Whenever you see a question about nested families in Revit, focus on two distinct concepts: shared parameters and the Shared family setting. These are separate features that are often confused, and exam questions love to exploit that confusion. The key behavior being tested here is how Revit decides whether a nested family becomes an independent, schedulable element in the project or simply "disappears" into its host. By default, a nested family is absorbed into the host — Revit treats the whole assembly as one element. To make each nested sensor appear as its own project component that can be scheduled, tagged, and selected independently, you must enable the Shared checkbox inside the nested sensor family itself, then reload it into the host family, and reload the host into the project. That's exactly what D describes, making it the correct answer. A is wrong because changing Sensor ID to a type parameter affects how parameter values are distributed across instances or types — it has no bearing on whether Revit registers the nested family as a separate project element. B reverses the logic entirely: marking the host as Shared does nothing to promote nested content into the project; the Shared setting must live inside the nested family itself. C is a trap for students who confuse Identity Data grouping with schedulability — moving a parameter to a different group changes its organizational category in the properties panel, not how Revit processes the family's identity in the project. As a study tip, remember: the Shared setting lives in the nested family, not the host. If a question mentions nested families and scheduling problems, check the nested family's Shared checkbox first.

Question 10

A firm creates several door families that must report a user-entered Asset Code in door schedules and display the code in a custom door tag. The code must remain independently editable for every placed door.

Which family-authoring approach best satisfies all requirements?

  1. Add the same shared parameter definition to every door family as an instance parameter, and use that definition as a label in the door tag. (correct answer)
  2. Add a family parameter named Asset Code to every door family as an instance parameter, and create a text label with that name in the tag.
  3. Add the same shared parameter definition to every door family as a type parameter, and use that definition as a label in the door tag.
  4. Add a project parameter named Asset Code to one project as an instance parameter, and embed ordinary text with that name in the tag.
Explanation: When a question asks about parameters that must appear in both a schedule and a tag across multiple families, your first instinct should be: this requires shared parameters. Shared parameters are defined in an external .txt file, giving them a consistent GUID that Revit recognizes as the same data field wherever it appears — across families, schedules, and tags. Choice A is correct because it satisfies every requirement simultaneously. By adding the same shared parameter definition to each door family as an instance parameter, every placed door gets its own independently editable Asset Code value. Because it's a shared parameter, you can add it to a schedule as a reportable field and use the same definition as a label in a tag family — Revit links them by GUID, not just by name. Choice B fails because a family parameter (non-shared) cannot be scheduled in a project schedule or used as a label in a tag family. It exists only within that one family's internal logic. Even if you name it identically across families, Revit has no mechanism to treat them as the same field. Choice C is close but wrong because making it a type parameter means all doors of the same type share one value — you cannot edit the code independently per placed instance, which violates the stated requirement. Choice D fails on two fronts: a project parameter cannot be used as a label in a tag family, and embedding static text in a tag doesn't read live data from any element. Study tip: Memorize this rule — if a value must appear in both a schedule and a tag, it must be a shared parameter. No other parameter type bridges both.