Zombie Parameters linger after delete from project parameters

@jacob.small - Link-back to original topic: Delete unused shared parameters?

Here is an example of the Zombie Parameters ; ) Images inside file as well for reference in a fres no-template file fully purged… R23*
Zombie-Parameters-Example.rvt (800 KB)

This has been a long-standing issue in Revit : (
Started by adding parameters

and another:

Then delete:
2023-03-28(Revit) t105430 Autodesk_Revit_2023.1_-Project1-_Floor_Plan_Lev


Deleted parameter:

And the other parameter for reference:

If we could run a DYN player or a PyRevit or have Autodesk fix the issue that would be fantastic.

@SeanP - repost from other thread if you have suggestions as well.

Snoop it before/after deletion. Is there any parameter that changes to indicate its in the model but ‘deleted’? If so that could be used to delete zombie parameters only from all the SharedParameterElements potentially.

1 Like

Still not sure I see the issue… "There is data in the file which is only visible to users via the API isn’t a problem or bug. IT’s actually qutie common and required for file stability. I guess they could swap the name…

What is the problem presented by having these extra parameter elements in the file? On a scale of 1 to 10 where 1 is “a handful of BIM managers who’ve found how to identify these exist” and 10 is every single Revit user globally, how many are impacted by this, and how so?

Even without seeing the issue, this appears to be pretty simple to do.

The parameters in use by the project parameters can be pulled using the ParameterBindings property of the document. The shared parameters elements can be collected by filtered element collector, which allow pulling the definition with the GetDefinition() method. The binding map can be checked to see if it contains the definition with the Contains() method. If that contain test wasn’t true, you can delete the object from the document with the Delete() method of the document. Otherwise you can move on.

Overall it looks something like this:
import clr
# Import DocumentManager and TransactionManager
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
# Import relevant sections of the RevitAPI
from Autodesk.Revit.DB import Document, SharedParameterElement, FilteredElementCollector
doc = DocumentManager.Instance.CurrentDBDocument #the active document 
TransactionManager.Instance.EnsureInTransaction(doc)# Start Transaction
bindings = doc.ParameterBindings #get all the parameter bindings in the document
sharedParameters = FilteredElementCollector( doc ).OfClass(SharedParameterElement).ToElements() #get all shared parameters in the document
results = [] #an empty list for our results
for sp in sharedParameters: #for eveyr shared parameter perfor the following
    spDef = sp.GetDefinition() #get the definition of the shared parameter
    test = bindings.Contains(spDef) #test if hte bindings map contains the defintion
    name = sp.Name #get the name of the shared paramter
    if not test: #if the definition was not in the bindings map
        doc.Delete(sp.Id) #delete the shared parameter
        results.append("Shared Parameter {0} was deleted.".format(name)) #let us know the parameter has been deleted
        results.append("Shared Parameter {0} is in use.".format(name)) #let us know the parameter is in use
TransactionManager.Instance.TransactionTaskDone()# End Transaction
OUT = results #return the results to Dyanmo environment

Note this won’t check to see if it messes with your families - that’s a bigger issue and I believe why the Remove Project Parameter doesn’t go nuclear at first. I believe you’d have to open each family document 1x1 to confirm it doesn’t break something else, which is a time consuming process. Would love to hear otherwise though.


I think the only scenario here it impacts is if a parameter doesnt change guid but changes unit or name. Definitely a 1/10 task for sure.

Handy code! Time to make a pyrevit tool for it in my secret BIM manager tool tab…


Just be careful with it. I’m really cautious of adding a ‘delete’ to something that the Revit team hasn’t already automated… The Revit team usually has very good reasons for not doing so and I usually overlook that reason until I’ve fowled something up.

1 Like

I’ve done it before in the past manually so I believe it should be OK, but yeah fair point. If we cant remove it then I would have thought the team would build in an error at least surely ala trying to delete the int origin.

1 Like

Good point, but always proceed with caution. If I recall it was only a few releases back where we could delete every single view in the file, and save. Next time you open “there are no views in this file so we can’t open it” error appears.

1 Like

Works like a charm! Thanks @jacob.small !

Not sure how it got in there- might be Ideate unlocking something it shouldn’t. Tried this morning and kept getting a warning “Associate at least one element to associate with parameter” on trying to remove it.

Really helpful though for same-GUIDs with different info (Or info updates!!!)

Routine with copy-paste winform attached:

Parameter-Purge-Unused.dyn (11.7 KB)