Tag Settings Schema fixes

11 min. readlast update: 11.14.2025

With the updates to Core.MEP.Fabrication v3.10.0.2 and v3.11, Naviate has built-in process that occur in order to mitigate the Tag Settings Schema conflicts as much as possible. Please refer to the following information that summarizes causes for the conflict errors and how to resolve using Naviate.

Schema Conflict Causes

Note: this section is copied from the 3.10.0.1 Hotfix Release Notes, with amendments noted in this manner.

·         The Tag Settings schema is defined by Naviate for storing Tag Settings data in the model's Extensible Storage.

·         Once the Tag Settings schema is loaded into the model, by Naviate, it remains in the model (sometimes, even if the add-on is not loaded).

·         When Revit opens a model containing a schema, this schema is loaded into memory of the Revit session and used for all projects that contain the same schema definition.

·         Conflict occurs when Revit loads a second model (directly or as a link) which contains the same schema (by a unique identifier, or GUID) but with a different definition.

o   Specific to Tag Settings, the conflict occurs when a session of Revit first opens a file and saves one 7100xxx GUID Schema, then opens a second Revit file (directly or as a link) with a different 7100xxx GUID Schema.

o   Note, the Conflict Error will appear if a Revit file containing either TagSettings Schema #1 OR TagSettings Schema #2 is opened, then loading a second file containing the other Schema in the same Revit session.

§  The reason for the Conflict Error is that the same Schema with GUID 7100xxx has two (2) different Schema definitions. As seen in Figure 18, the values for Members (1) “Documentation”, (2) “WriteAccessLevel”, and (3) “WriteAccessGranted” have different values between Schema #1 and Schema #2.

·         Example 1 – scenario of opening multiple Revit files in the same Revit session:

o   ProjectA – contains Schema #1

o   ProjectB – contains Schema #2

o   In one Revit session, if ProjectA is opened first, then ProjectB opened, the Conflict Error will appear.

o   In this same respect, in a separate Revit session, if ProjectB is opened first, then ProjectA opened, the Conflict Error will also appear.

·         Example 2 – scenario of opening a Revit model with a conflicting Linked model

o   ProjectA – contains Schema #1

o   ProjectB – contains Schema #2

o   ProjectA is the host model that contains ProjectB as a Linked model.

o   The Conflict Error will appear in both of these scenarios:

§  ProjectA is opened with ProjectB loaded as a Link by default.

§  ProjectA is opened with ProjectB unloaded. When ProjectB is later reloaded as a Link, the Conflict Error will appear.

·         Example 3 – scenario of opening a Revit model with two (2) or more conflicting Linked models

o   ProjectA – contains Schema #1

o   ProjectB – contains Schema #2

o   ProjectC is the host model that contains ProjectA and ProjectB as a Linked model.

o   The Conflict Error will appear in both of these scenarios:

§  ProjectC is opened with ProjectA and ProjectB loaded as Links by default.

§  ProjectC is opened with ProjectA and/or ProjectB unloaded. When ProjectA and ProjectB are later reloaded as Links, the Conflict Error will appear.

o   Note: ProjectC could have one of either Schema #1, #2, or no Schema, and the Conflict Error will still appear.

·         Schema #1 is generated when Tag Settings are created in Naviate Fabrication v3.9 and prior

·         Schema #2 is generated when Tag Settings are created in Naviate Fabrication v3.10

A screenshot of a computer

AI-generated content may be incorrect.

Figure 18

Solution

In the v3.10.0.2 Hotfix and Release Version 3.11, the solution to the TagSettings Schema Conflict Errors is designed to target any instances of Schema #2. Once Schema #2 is detected when opening a Revit file, the schema is purged, with Tag Settings then utilizing new schema GUID.

 

Schema Updated: Auto Detection and Update of Schema #2 on Document Open

On document open (or when Revit opens a file, such as .rvt, .rfa, .rte, etc.), v3.11 of Naviate Core.MEP.Fabrication will detect if Schema #2 is saved to the file currently attempting to open. In the event that Schema #2 is saved to the Revit file, the notification message as depicted in Figure 19 will appear instantly, before the file attempts to opens

 

 

RevitFileName

 

A screenshot of a computer error

AI-generated content may be incorrect.

Figure 19

A screenshot of a computer error message

AI-generated content may be incorrect.

Figure 20

 

Note: The notification message in Figure 19 replaces the Revit out-of-the-box Conflict Error message as depicted in Figure 20.

Why does ‘Schema Updated’ (Figure 19) appear?

Naviate will automatically update the detected Schema #2 to a new Schema, while also removing Schema #2 from the Revit file. Because schemas are saved on the Revit session level, the schema is not completely removed until the current file is synchronized/saved and the Revit session is closed. Knowing this behavior of schemas, there are two (2) options for how to proceed:

1.       Save and Close or Sync and Close – this button will appear with either ‘Save…’ or ‘Sync…’, depending on whether the file is a detached model or a workshared model. Click this button and Naviate will save or sync the model, then automatically close the session of Revit in order to completely remove the trace of Schema #2 from the file. You can then open this file in a new, separate session of Revit and proceed with your normal work.

a.       Note: If you then open this file in a new session of Revit, Schema #2 will no longer be found in the project, thus avoiding any Schema Conflicts in the future.

b.       Note: if multiple files are also opened in this current Revit session to be closed, the normal popup messages will appear for each file, asking whether the user would like to save/sync the model before closing the Revit session.

2.       Later – click this button to continue opening this Revit file, as normal, and proceed working in the file. It is not advised to continue working in this Revit session because Schema #2 will remain in the session until this instance of Revit is closed. This could lead to subsequent Revit files potentially being introduced Schema #2 again if opened in this same session of Revit.

a.       Instead, it is advised to save/sync and close the Revit session immediately to complete the schema update.

b.       If subsequent Revit files are attempted to be opened in this session of Revit (without closing), the Schema Updated dialog (Figure 19) will continue to appear for each Revit file opened, reminding that this Revit session is advised to be closed immediately to completely remove Schema #2.

Note: Revit 2021, 2022, and 2023 require an additional, manual step for the Schema to be completely purged and updated. It is advised to click OK, go to Manage > Purge Unused, Check None, look under Extensible Storage Schemas, purge the ‘7100xxxx’ Schema, and Save/Sync the file. You may need to Purge Unused and Save more than once for the Schema to be completely purged. Once purged, it is advised to close Revit, start a new session, then open this file.

 

Schema Conflict Detected: Multiple models open in one Revit session causing conflict

On document open (or when Revit opens a file, such as .rvt, .rfa, .rte, etc.), v3.11 of Naviate Core.MEP.Fabrication will notify the message in Figure 21 if a Naviate-based schema conflict occurs. Currently for v3.11, Naviate only can detect linked model, Naviate-based schema conflicts related to Tag Settings.

Figure 21

Why does ‘Schema Conflict Detected’ (Figure 21) appear?

Naviate will display the notification message in Figure 21 when a schema conflict exists between the first model “ProjectA.rvt” opened in the Revit session, and other Revit files open in the same session “ProjectB.rvt” (Example 1 under Schema Conflict Causes above).

The following are the two (2) options in this dialog:

1.       Open New Session – clicking this button will cancel the load of the Revit model ”ProjectA.rvt” for example, and open a new session of Revit. The intent with this option is to use the new session of Revit to the file that contains Schema #2 saved to it with v3.11 and follow the steps in “Schema Updated: Auto Detection and Update of Schema #2 on Document Open”. Once these steps are completed for any models that contain Schema #2, you can then open both “ProjectA.rvt” and “ProjectB.rvt” in the same Revit session.

2.       Do Not Load – clicking this button will cancel loading the second Revit file and return to the previous Revit window. The intent of this option is for you to continue working in “ProjectA.rvt” and update the Schema #2 later. It is strongly advised to update the Schema in “ProjectB.rvt” in a separate session immediately to avoid potential introduction of Schema #2 to a subsequent Revit file.

a.       Once these steps are completed for any models that contain Schema #2, you can then open both “ProjectA.rvt” and “ProjectB.rvt” in the same Revit session without conflict.

 

Schema Conflict Detected: Linked Model causing conflict

On document open (or when Revit opens a file, such as .rvt, .rfa, .rte, etc.), v3.11 of Naviate Core.MEP.Fabrication will notify the message in Figure 22 if a Naviate-based schema conflict occurs. Currently for v3.11, Naviate only can detect linked-model, Naviate-based schema conflicts related to Tag Settings.

Figure 22

Why does ‘Schema Conflict Detected’ (Figure 22) appear?

Naviate will display the notification message in Figure 22 when a schema conflict exists due to Linked Models, (either Example 2 or Example 3 under Schema Conflict causes above).

To resolve the issue, it is advised to open any linked Revit models in a separate session in order to update any instances of Schema #2 that are saved to those models. Please repeat the steps outlined in the section “Schema Updated: Auto Detection and Update of Schema #2 on Document Open” for any possible linked models.

The following are the two (2) options in this dialog:

1.       Open New Session – clicking this button will cancel the load of the Revit model ”ProjectA.rvt” for example, and open a new session of Revit. The intent of this option is to use the new session of Revit to open any of the Linked Models that could contain Schema #2 saved to it with v3.11 installed and follow the steps in “Schema Updated: Auto Detection and Update of Schema #2 on Document Open”. Once these steps are completed for any models that contain Schema #2, you can then open the original model ”ProjectA.rvt”.

a.       At this time, Naviate is not able to detect which Linked Model specifically is the one that contains Schema #2.

2.       OK – clicking this button will proceed opening the Revit model ”ProjectA.rvt”, with any linked models loaded as last opened. Although this option is not advised, it will allow you to open the model and work with a schema conflict only existing in linked models. Any unloaded linked models can be reloaded by going to Manage > Manage Links and reloading any desired links.

a.       It is advised instead to open any linked models that could contain Schema #2, in a separate Revit session, and follow the steps of ”Schema Updated: Auto Detection and Update of Schema #2 on Document Open” to update Schema #2 and avoid further conflicts.

b.       Please note that as links are loaded back into ”Project.rvt”, a Schema Conflict error could reappear if two (2) or more models have a conflicting schemas.

 

Updating the Tag Settings Schema to the new GUID

On document open (or when Revit opens a file, such as .rvt, .rfa, .rte, etc.), v3.11 of Naviate Core.MEP.Fabrication will automatically update the TagSettings schema, preventing the possibility of conflicting 7100xxxx GUIDs being created in the future. The reason for this update is to only use one (1) Schema moving forward, starting with v3.11, and abandoning any previously used Schemas.

The following are behaviors that occur when a Revit file is opened with v3.11:

1.       If TagSettings Schema of GUID 4078dfde-0f06-4ac1-b9b7-aeda9c1b2430 is found in the file, use Tag Settings Data in this Schema for [N] Fabrication Tag Settings.

2.       Then, if TagSettings Schema of GUID 6ae8a7af-e74b-4b68-8790-7a06aa39a7a1 OR 662378b2-7b76-4c3c-7c01-01251b4c0c66 is found in the file, read the Tag Settings Data and upgrade the Schema to new GUID 4078dfde-0f06-4ac1-b9b7-aeda9c1b2430 to be used in v3.11 and forward.

3.       Then, if TagSettings Schema of GUID 710020d6-fa0d-4ee7-86d5-437caa34da2d is found in the file, read the Data Storage Elements, upgrade the Schema to new GUID 4078dfde-0f06-4ac1-b9b7-aeda9c1b2430 to be used in v3.11 and forward. Schema #2 will be purged if detected. The Tag Settings Data in Schema #1 will remain in the model to be used by Naviate Accelerate, see note below.

 

·         Note: Naviate Accelerate will continue to use Schema #1 as depicted in Figure 18. Naviate Accelerate and Naviate Fabrication will utilize different Schema starting with v3.11 of Naviate Fabrication.

o   Because of this change, Naviate Accelerate and Naviate Fabrication will have separate TagSettings data storage elements, meaning each product will display separate Settings saved to its associated Naviate product.

o   If TagSettings are desired to be read by the other Naviate product, the TagSettings storage must be exported to a separate file, then imported into the desired product.

§  For example, in order for the Tag Settings saved in Naviate Accelerate to appear in Naviate Fabrication, the settings in Accelerate must be exported to a .json file. Then, that .json file can be imported in Naviate Fabrication for each product to display the same TagSettings Configurations.

A screenshot of a computer

AI-generated content may be incorrect.

Figure 23

The new TagSettings schema that will be utilized in v3.11 Fabrication is displayed in Figure 23. The GUID for this new schema is 4078dfde-0f06-4ac1-b9b7-aeda9c1b2430.

Refer to 3.10.0.1 Hotfix Release Notes, for additional information.

Was this article helpful?