Renaming Shared Parameters

I think FamilyDocument.AddSharedParameter from Orchid package is what you need to begin.

Forgive me if I am wrong here, but is that just to add a Shared Parameter? Sure it was quick to add them in Revit which I already done. I want to somehow get a parameter from a door family and change it to a new parameter.

why not add it to the Category instead, a lot easier and more freedom to Tag and create schedules from.
if its not driving geometry that is


Yes they are all driving geometry

there is also a node for adding parameter values in the Orchid package.
SetParameterByName and SetFormulaByName

According to changing names for shared parameters … that should always be very very hard to do, it is not at all a trivial process to do, I should only be for top experts to do. I know it is doable, and I have also done it, but I did consider it profound before I did it.

Problem is previously projects if you change the name in a shared parameter and projects are archived. What if they were connected by the parameter name, then the connection would be lost.

Before dynamo, it was difficult to copy values from one parameter to another, so this renaming options well hidden was an option know by experts. But with dynamo, where it is very easy to copy a value from one parameter to another I would NEVER do this renaming anymore, it is simply not the proper way to work.

Thank you
It would not effect any recent projects as I am still developing the template. I ended up creating the new SP’s and just opened every family and assigned the existing to the new, and once all new ones were assigned across all families and the template schedules, I just deleted the old ones. It took a while, but it’s done now.

I still think it should be straightforward to change the name though, regardless of whether it is best practice or not, especially since it was perfect for my situation. There just should be an error highlighting what you mentioned about previous projects. Errors can pop up many times in Revit for most people, and they choose to ignore them, so why should renaming SP’s be any different. I see mistakes happen everyday!

I will check out that node just to know for future reference. Out of curiosity, how did you change the name in the past?

There was the very well hidden trick with renaming the shared parameter, which I never shared with anyone, since it is absolutely not recommendable, no matter what. It is, in fact, a bit worrying that it can be done, it should not be allowed under any circumstances.

From a manager perspective for a company would this be the worst nightmare if anyone else than yourself knew how to do it. So no one at all should have the opportunity to do it. Also back in time has there existed other options when copying parameter values, export values to txt/csv/xclx files and import again are one option.

But with dynamo has it become so easy to do, so no one should be creative and rename shared parameters.

I would anytime vote against easy access to rename shared parameter as long as they are depended on GUID. I never hope Autodesk will consider that. I will even prefer if they closed the option totally to rename shared parameter.

1 Like

So you won’t tell me how you did it? There are many plausible reasons why one would need to change the name of a SP; there is my case, company and national standards changing, amongst others. If SP’s are mapped to a txt file, with each SP having a GUID, then is it not the case that the name is irrelevant? If you change the name, the txt file will update and any project linked to that file will update. (I may be wrong here, but it is my limited understanding)

It can not all be about Doom and Gloom. Like I said, there are mistakes made everyday with errors, etc. Its all down to proper management and proper training.

Like @echo said, copy the value from one parameter to the other, that is the proper solution.

Having an option to SetSharedParameterByGUID would also be doable as @Marcel_Rijsmus mention, since it goes on the guid and not the name whatever it might be. I am sure that I can build such a node, but such a node would only be for experts, so maybe not really needed since that kind of user always would be able to solve such problems.

Renaming SP is not a doable solution.


Yes that is what I done as I already mentioned. I copied everything. It still look a day of work to remap everything. There must be a simpler solution, and you have one so in order for me to become this so called expert, I would love to know it please. Either with being the node you could possibly create, or the way you done it in the past.

The nodes are present… that was what i described in my first post. Create a new SP parameter, named correctly. Get the values form the “old” parameter, put it on the “new” parameter, and then you are good to go. It can be done using my orchid nodes for families, and for projects use the OOTB nodes.

the below is a quick hack how it could look like
newSPparam.dyn (15.9 KB)


I would love to see the node Erik
And i wonder where the data goes if someone uses the add shared parameter option in the family environment and loads the family in a project where the same parameter has been set to the category the family is in. With all options like Type Parameter in the Family, Instance Parameter in the project and the other way around.

Maybe @erfajo can shed some light on this.

It looks very doable… Jeremy has a solution and likewise at Autodesk forum.

But I don’t understand the need for such a node for users in general. Shared Parameters is something there should be maintained on a company level, and they should focus on naming the parameters, let Autodesk take care of the guids. It is the guids that ensure that two parameters named the same in different settings doesn’t cause breakdown in data structures. So my aim is simple, don’t mess with the guids :slight_smile:

Transfering values between families and projects, can you give an example where that is needed? I imagine that it is doable, but it might include some data middleware, like a txt/csv/xlsx file.


Is it possible to do something like this with element types? or is it exclusive for .rfa

I have nodes for project parameters as well, these are nearly the same as the OOTB nodes.

Try to change the nodes for family documents with the comparable nodes for a “project”

Hi Eric,

we just experienced this like the company consolidate the business name, so we need to do bulk update with new prefix. I have tried what you said. but it dosent create the new shareded parameters with existing value. could you please help to identify the issue? Many thanks in advance.

@dylanpeng, did you ever resolve your graph? If yes, what was wrong?

What I had to do was simply create a New Template (RTE) & at the initial creation, Renamed the SPs in the file & did a Save As…(new name.txt) {this is the so called “taboo” part} & loaded all my SP’s into a virgin RTE file; then removed all SP’s from Project Parameter list. Then transferred all project settings from the original RTE (just had to recreate Model views, & assign View Type Settings to Sect/Elev/etc…). This was way more efficient than replacing the tons to SP’s I had in RTE & my content library. My SP count range is +100-150.

@Marcel_Rijsmus, is this what you were hoping would be invented?

Create project parameters by using the exported Shared Parameters from a Family

@JustinStirling No, what i am after is to get and set parameter values by parameter GUID (if there are parameters with the same name).