I made a critical mistake when launching my BIM program at one of the largest tech conglomerates in the world… Oh, and I found a way to fix it, too.

I have always felt that BIM standards should always focus primarily on the data structure of models, not so much the graphical output on drawings (let’s agree to keep calling these CAD standards). In the Revit world, Shared Parameters are the properties within a Revit model which hold BIM data, making them one of the most foundational pieces of a Revit BIM standard.

These special parameters can be difficult to manage once they’ve been loaded into a project or family, as they cannot be renamed and are technically impossible to completely purge from a model. Ask any seasoned Revit designer and they will agree that it takes some backend wizardry to fully delete a Shared Parameter once it has been defined in a project. Sure, you can easily delete a Shared Parameter, but the reality is the parameter remains hidden in the model, invisible to the frontend.

This is why a solid strategy around Shared Parameters is required at the onset, as it can save you from lots of headache later on down the road. Last week, I finally reach the part of the road where my Shared Parameter strategy failed… Luckily, I found a fix.

The Problem

Naming conventions and descriptions in shared parameter definitions are what most BIM managers would agree are important, however the most critical property of a Shared Parameter is often overlooked, its data type. As one would expect, data types cannot be modified once loaded into a project, yet we still commonly see incorrect data types throughout the industry.

This is where the critical mistake happened. I found a few Shared Parameters which had incorrect data types, so I changed the data type from INTEGER to TEXT. In retrospect, I should have simply created a new parameter if I didn’t agree with the data type.

The problems start to surface when a Revit project which already had the Shared Parameters loaded with one data type (i.e., INTEGER). When a user attempts to load a family which has a Shared Parameter with the same GUID and a different datatype defined (i.e., TEXT), they will anger the Revit Gods and be prompted with the following error:

“The shared parameter ‘X’ cannot be added with name ‘X’ and type ‘<Type>’ because it conflicts with the existing name ‘X’ and type ‘<Other type>’” in Revit.”

Error message in Revit when Shared Parameter data types don’t match

As you can imagine, this had a negative downstream impact to our organization-wide BIM standard; technically, my program’s entire library of Revit families was no longer compatible with other programs’ Revit projects. Oops.

Sure, I could easily delete the Shared Parameters from all families, but I still wouldn’t be able to use them in both programs because Revit somehow does not let you fully delete Shared Parameters. Although Autodesk states that you can delete a shared parameter from a project or family from the frontend, this technique does not fully “purge” this definition from the family or project. Most likey because the parameter you have tried to delete is loaded into other families in the project.

If you want to test this limitation, try deleting a Shared Parameter from a Revit model and loading a parameter with the same GUID but a different name. It will always assume the original parameter name that was defined in the project or family.

The Fix

With all of that being said, how do you fully purge Shared Parameters from a Revit project or family? Well, the good news is I found a simple low-tech solution that does not require Dynamo scripts or writing code. 

1) Reveal “deleted” Shared Parameters using the RevitLookup add-in by Jeremy Tammik.

RevitLookup is an open source (i.e., free) add-in provided by Jeremy Tammik, one of the industry’s most influential Revit API developers. Put simply, this add-in surfaces countless objects and properties that are not exposed in the frontend of the Revit application. RevitLookup allows end-users to inspect the data within a Revit project or family in a similar way that a developer would use the Revit API to do so programmatically.

This add-in will expose the parameters that have been so-called “deleted”.

Download the RevitLookup add-in here: https://github.com/jeremytammik/RevitLookup

2) Use SnoopDB to find the Element ID of the Shared Parameter.

Once the add-in is installed, open the Revit model you would like to inspect and navigate to the Add-ins Tab > Revit Lookup > Snoop DB. This will launch the Snoop Objects window and display the underlying objects within your model in a tree on the left pane. Along with some familiar Model Categories, a set of objects grouped under “SharedParameterElement” is also listed.

In this example, I’m looking for a shared parameter named “Barcode” which has already been deleted from my Revit project. After expanding the list of SharedParameterElements in RevitLookup, I found an item named <Barcode 1093199>.

Yes, you guessed it. The numerical piece of this name is the Element ID for this shared parameter. I don’t know about you, but simply seeing that Shared Parameters have Element IDs was eye-opening. At this point, my initial thought was if a thing in Revit has an element ID, you can most likely delete it!

Right-click on the Id row and select “Copy” to copy the element ID to your clipboard.

3) Select Element by ID

Now that we have the element ID of the Shared Parameter stored in our clipboard, we can use Revit’s out-of-the-box tool to select the element using the element ID. This is as simple as navigating to the Manage Tab > Select Elements by ID.

Paste the element ID that you copied to you clipboard in step two.

Once you click “OK” you’ll notice something very interesting has happened…

Looking at the ribbon and contextual menu, you can see that the Shared Parameter itself is selected! I’ll let that sink in for a minute.

4) Press the Delete key

Yes, just literally push the delete key on your keyboard while the Shared Parameter is selected to purge the Shared Parameter.

Warning: Data Loss

I should warn you that if you followed these steps in a Revit project, it will delete the Shared Parameter that is loaded into all families within the project as well. It completely wipes the Shared Parameter out, regardless of it is a project parameter or a shared parameter loaded into a family.

This means this workflow has the potential for lots and lots of data loss, so please purge Shared Parameters with care. However, it also means you can easily purge a Shared Parameter out of an entire project (including all families) in just a few steps.

Problem solved.

Having mismatched data types in Shared Parameter definitions can have massive downstream impacts to efforts in implementing a data standard and I’m happy to report that the my program’s families are now compatible with Revit projects across my entire organization; A big win from the geeky BIM-side of our business.

Future State: An OpenDefinery Add-in

A bit of a shameless plug here, but I am working on a Revit add-in for OpenDefinery. This desktop application will include a feature to delete and purge Shared Parameters from projects and families.

Watch this space for updates and follow our open source project on GitHub to stay up to date: https://github.com/jmerlan/OpenDefinery-DesktopApp