NBS Plug-in for Revit - the parameters that are used

I've had two or three sessions with customers in recent weeks who want a deeper dive into exactly what parameters the NBS Plug-in uses to connect objects to specification clauses. This blog post summarises this. There is also a support article on our Chorus forums about this:
https://support.thenbs.com/support/solutions/articles/7000043835-parameters-inserted-into-objects-after-association

The screenshot below shows three instances of the same type of washbasin in Revit. The schedule shows the NBS parameters that are inserted into an object when linked to NBS Chorus. These will be inserted into any object - the object could be from National BIM Library or an object a practice has created or an 'out of the box' Revit object - it doesn't matter.

Click the screenshots below to see larger views.

A schedule showing the parameters that will be used

The screenshot below shows how an association can be made between the Revit object and the NBS Chorus clause...

Associate an object with the specification clause

Once the association is made, the parameter values are populated. It should be noted that the expectation is that the NBSChorusProjectId, NBSChorusSpecificationId and NBSChorusClauseId parameters are ignored and are just hidden in the background. But in this blogpost I've highlighted them to show the mechanics of how the associations are made and retained. The NBSChorusPrefix, Uniclass2015Code, Uniclass2015Title and NBSChorusSuffix parameters are expected to be used in schedules and annotations.

The parameters are populated

Again, not something that most users will want to know - but the URL of the specification location matches the GUIDs used in the Id parameters. These are highlighted in colour below and in the screenshot.

In this specific case:

URL=https://chorus.thenbs.com/org/ef335f70-956f-11e8-9420-5985807a4792/project/4eed4d80-cdb9-11ea-af47-1dfdb8ac8056/spec/f30feab0-259a-11eb-abbe-11959d020b9b/viewer/clause/8eef6922-13b8-4c10-9e9f-81537f981558

NBSChorusProjectId=4eed4d80-cdb9-11ea-af47-1dfdb8ac8056

NBSChorusSpecificationId=f30feab0-259a-11eb-abbe-11959d020b9b

NBSChorusClauseId=8eef6922-13b8-4c10-9e9f-81537f981558

The GUIDs can also be seen in the web URL

By maintaining these GUIDs it is possible to maintain the association even if the visible parameters used in scheduling/annotating change as shown below.

The visible parameters may be changed

When the visible parameters become out of sync - the plug-in allows the user to synchronise these once again.

The GUIDs retain the associations and flag any changed visible parameters

By keeping the information coordinated, the drawings and schedules exported from the model can be kept synchronised with information in the live specification.

The plug-in assists with re-synchronising the visible parameters

A few notes to finish on.

Note 1: The rules above apply to Revit system and component objects. For material objects a '_mtrl' suffix is added to the parameter names

Note 2: The above example is for Uniclass 2015 classifications. Similar parameters with slightly different names (for example CAWSCode...) are used for other classification sets such as CAWS or Omniclass.