Create Project Parameter from Shared Parameter


No nodes build by anyone, and this goes as well for what can be found at for Revit plugins can create project parameters as it can be done inside Revit. Why noone in the Revit team has found it applicable to provide us with this option I really cant say.

This is why I mentioned for @Michael_Kirschner2 that the dynamoteam should remove the input option concerning “group”, since it makes no sence from a “ProjectParameter” point of view. This issue is filed at DynamoDS Github.

The remaining part is that all you have been writing indicates that it is not a Project Parameter you ask for but a Shared Parameter you can add to the project. This will inside the project act as a Project Parameter with some benefites.

Since noone besides the Revit team can add real project parameters it really doesn’t matter, since you one way or the other will get these parameters as shared parameters.

So instead of having troubles with trying to add project parameters, add Shared parameters instead.


If you recreate the graph extract below and run it then the following should happen;
Parameter.CreateSharedParameter will create a parameter Tested in the group Testing in your shared parameter file if it doesn’t already exist. If it does exist then you shouldn’t see anything change.

Parameter.AddSharedParameter will create a shared parameter in your shared parameter file if it doesn’t exist AND also create a project parameter at the same time, which is what I understand you want to do. This node is not OOTB and is in the Orchid package created by @erfajo.
if you find the graph doesn’t behave accordingly then I recommend closing Dynamo and perhaps the file Revit file you are using and then trying again.
I also recommend freezing the Parameter. node you aren’t testing to fully understand the differences between them when you run them.
Hope that helps and is what you were looking for.



hi @Marcel_Rijsmus, I have looked at the “openRFA” site, and I am worried about this site. It seems that they try to organize shared parameter guids to be the same. However, they make one major big mistake… they have not included the team behind the Revit IFC exporters shared parameter guids!

In other words… I will warn against using those parameters!

Use the file IFC Shared Parameters.txt instead! this works together with the IFC exporter!

The most important parameters are…

PARAM f53d1285-ae3d-4992-a3f1-2e7978be529a IfcExportAs TEXT
PARAM 8296d5c9-f935-41f5-8247-48a26d1c85a4 IFC CAD Layer TEXT
PARAM 99793364-7511-4937-80d1-4a6427f2c720 IfcDescription TEXT
PARAM 765c61bc-7588-4846-bfef-befb28681767 IfcExportType TEXT


bringing in the parameters is what matters here.
we need to create the parameters with the correct GUID
it could be any shared parameter file, and this one is not mine and just an example
i have seen Jeremy’s work following your link, if it cant be done it cant be done
appreciate your efforts tho
and @antevasin’s too which i have not tested but seems promissing

there must be some misunderstanding here somewhere, as i cannot believe that @mdhutchinson and i are missing the point
is Jeremy saying every parameter bought into the project is a shared parameter by definition?
listed as (shared) project parameter or not?


is Jeremy saying every parameter bought into the project is a shared parameter by definition?

New parameters can only be created as shared parameters

Which is what Erik was saying…

That’s from 2008… @Jeremy_Tammik has anything changed? :slight_smile: (My guess would be No!)


Edit This is 2016…


My guess is no, too. Happy New Year!


@Marcel_Rijsmus, aha… got it… just an example :slight_smile:

First… Well bringing in the shared parameter file is some of the new nodes I have made. So this is doable now. However, i still need to work on the issue you mentioned.
Next… I have started making a node which takes the most essential IFC parameters from the IFC Shared Parameters.txt to be added automatically. I hope to release this soon :slight_smile:

Lastly… yes @Jeremy_Tammik and I are saying the same… I would wish I was wrong, and I have tried all kind of workarounds, but I gave up and ended as everyone else concluding that for us outside the Revit team, there is only one option to add parameters.

By the way, thanks for your very valuable page @Jeremy_Tammik. I started coding using your page as my source back in 2010-11 (where we had some brief contact)… I am still following your site even I don’t need it that much anymore, but it is still very lovely to follow what you do… also when it is not coding as such you post :slight_smile:



try to see this node… “AddIfcParameter”



thank you for your appreciation!


Hi @Marcel_Rijsmus

I have tried to work on this node where i get the guids of a parameter… is it something like this you are asking for?

Please note, the node is not released yet, but I will do it if this is what you ask for :slight_smile:

As you can see from the image, I found a lot of shared parameters in my test project which is not available as project parameters, but they are present in the project file!?.. deleting them was easy and gave me a more clear file :slight_smile:


Hi Erik

It’s getting really interesting now!
What i miss is the check with shared parameter file to keep only those parameters.
I guess it can be done with OOTB nodes, but it would clarify the process for others too.
Good job!
Do you have nodes which can give me a decisive answer whether the parameter originates from the project or a family?


I have released beta builds for 1.3 and 2.0 series at Github, I have changed the nodes slightly from the previous image (I use the instead of adding this to the node as an outport).

I have tried different things to see if I could figure where the parameter is used, but I have not found a way to get this information unless I collect all elements and test their parameters.

I did test to add a shared parameter in a family, load it and then check this one new parameter I knew was used… but there was no difference for this parameter compared to all the others.

I tried to delete this new parameter from the project, and then it disappeared also in the family. However, if I deleted a shared parameter inside Revit, then it disappeared inside project parameter but was still available if I checked for shared parameters.

I then even tried to purge using my new node there takes everything else… but still did the shared parameters exist. Purging inside Revit did neither remove the parameter.

So there is a need as I see it to start observing all kind of project parameters using these new nodes… since Revit does not handle it!

Ass you write, you can combine these new nodes with other nodes including the OOTB nodes to make a workflow deleting the unwanted “wrong” shared parameters…

Please test the beta build and give me feedback if something needs to be added/changed.


Hi @erfajo

I ran this on a new project started by choosing none when it ask me for the project-template.
Can you explain?


i am not aware what Autodesk has put in their “empty” project template!? :slight_smile:

I got these… doing the same

if you want to use my nodes in the current document, then you don’t need to add the document, since I have coded this as the default value if the port is unassigned.

likewise can the ootb node for do the job for getting the name :slight_smile:


I use Element.Name+ beacause someone made it to use a bigger scope getting names. so my initial thought was why not use the bigger scope.
Maybe @JacobSmall can shed some light on what these parameters are/do, cleaning up my models i need to know what can be deleted
can’t seem to find them in here. further exploring needed, im on it, want to know @Luke_Johnson, @Jeremy_Tammik
btw @erfajo deleting a parameter by name is ok, but deleting a parameter by GUID is better i think, it will force you to know exactly what you are doing


Delete by guid… I will try to see what I can do asap :slight_smile:

However, I am struggling these days with the growth of my package. It holds now more than 150 nodes and I need to see if they can be organized better. Moving methods around comes with the backside of a need for migration, so users don’t end up with graphs not working. Therefore, have I started doing a UML diagram to gain an overview :slight_smile:


You help a lot of people out in difficult situations.
I like it


I have released the beta build nodes…


I just had this thought:
What if i could make those “loose” shared parameters into Shared Project Parameters with the categories still attached (no data loss). I can them delete them and investigate further if needed. But now i have control from the UI.


I don’t know what happens if you dig something up from the graveyard, I could give it a try asap…

Right now am I once more troubling with the closed Dynamo API, you need to build some many features over and over again due to protection by the Dynamo team.
I need to solve this one first and it is driving me crazy :slight_smile: