Model Coordination Issues FAQ
- What is saved when I create an issue?
- Why don’t I see the expected clashes when I open a clash issue?
- How can I see what was originally clashing in the issue?
- Why is clash data not available for my issue?
- Why does clash highlighting sometimes take a moment to appear when I click an issue?
- What is the difference between issues in Model Coordination vs Docs?
- What's the difference between an issue type and a template?
- What do the different issue statuses mean?
- What are the Location and Location details fields in issues?
What is saved when I create an issue?
Issues remember the models that were loaded in the viewer when the issue was created. When a member opens an issue in Model Coordination, the system checks whether any models that were present during the issue’s creation are not loaded now. If so, a dialog box displays asking the member if they want to load those models into the viewer.
Models that were not present during the issue’s creation are also ghosted. For example, a member creates an issue on a single model in Docs and then opens the issue in Model Coordination. The system ghosts any other models they have loaded in Model Coordination at that moment.
Issues do not remember basic or advanced filters. If the member filtered the model before creating an issue, Model Coordination won’t automatically reproduce that filtering when another member views the issue later.
Clash issues do remember clash highlighting and the isolation of the selected clashing objects.
Why don’t I see the expected clashes when I open a clash issue?
When selecting a clash issue in the viewer, sometimes Model Coordination will not highlight or isolate any clashes. Model Coordination may also show some, but not all, of the clashes originally associated with the issue. The main reason this occurs is because the clash has been resolved in the latest model versions, so there is no clash to show.
Clashes can be present against the placement model (the model on which the issue pushpin was placed), and also between other, secondary models. This means that there can be different combinations of clashes that have been resolved, and clashes that are still visible in the issue. Review the tooltips in the issue panel > Clashes tab, which provides more information based on the specific scenario:
It can also occur for other reasons, including:
One of the clashing objects is no longer in the coordination space. For example, in Docs, someone deleted the file containing the clashing object.
One of the clashing objects is no longer included in the clash check for the following reasons:
- In Clash Settings, a project administrator turned off clash detection for the model containing the clashing object.
- In Clash Settings, a project administrator created an object exclusion capturing the clashing object and therefore excluded it from clash detection.
The IDs of the clashing objects have changed in the authoring software, so the clash is no longer tracked to the issue. If the objects are still intersecting, they will appear as a new clash in the clash matrix. This can happen when:
- Someone has deleted and replaced the object in the authoring software, rather than simply editing it.
- The model was originally from an authoring software not supported in Model Coordination.
How can I see what was originally clashing in the issue?
When you open an issue in the viewer, if there are models that were open at the time the issue was created, but are not open now, a dialog is displayed giving you the option to open the missing models. This gives you greater context around the issue and any clashing objects.
If models or clashing objects associated with the issue are no longer available, as described above, you can refer to the issue thumbnail in the Details tab, which is automatically generated at the time the issue is created. However, project members can retake the issue thumbnail at any point, for example to reflect a newer state of the model that does not contain all the original clashes.
Why is clash data not available for my issue?
Sometimes the Clashes tab on the issue panel will show none or only partial clash information related to your issue. This can be for a number of reasons:
The clashes have been resolved, or the clashing model objects have been changed, deleted, moved, or excluded from clash detection. See Why don't I see the expected clashes when I open a clash issue?.
The clash check was unsuccessful. This can be due to:
- A problem with the placement model (the model that the issue pushpin was placed on).
- A problem with the other, secondary models associated with the issue.
To resolve this, you can try reuploading the models in Docs. For more information about unsuccessful clash checks, see the Clash FAQ topic.
Not all of the models involved in the issue are open in the viewer. For example:
- If only the placement model is open, no clashes can be displayed.
- If the placement model and some of the secondary models are open, then only clashes associated with those models are displayed. Other clashes involved in the issue will be missing.
To resolve this, you can add the missing models to the viewer:
- Close the issue details panel on the right.
- Click the issue in the Issues tab on the left to reopen it. If there are models associated with this issue that are not currently open in the viewer, a dialog is displayed that prompts you to add them.
- Use the Models not in viewer dialog to add the missing models to the viewer.
Models associated with the issue are in another coordination space, where the issue was created.
- If all of the secondary models associated with the issue are in another coordination space, no clashes can be displayed.
- If some of the secondary models are in the current coordination space, then only clashes associated with those models are displayed. Other clashes involved in the issue that related to secondary models in another coordination space will be missing.
To resolve this, switch to the coordination space that the issue was created in, and then reopen the issue.
A combination of the above scenarios can also occur.
Why does clash highlighting sometimes take a moment to appear when I click an issue?
When clicking a clash issue, the viewer may show a loading bar at the bottom left for up to five seconds, as it retrieves the clash data associated with the issue. It must do this before it can isolate the clashing objects and highlight them in red and green. Model Coordination will prefetch this data where possible, so clash data may show immediately when clicking other issues. This approach aims to minimize loading time for each issue, while protecting you from browser performance and memory problems that can be caused by loading too much clash data upfront.
If you click an issue and Model Coordination never shows any clash data, and there is no loading bar, see the other questions in this FAQ topic, for example Why don’t I see the expected clashes when I open a clash issue?.
What is the difference between issues in Model Coordination vs Docs?
In Model Coordination, issues can be created against either a single model, or, more commonly, against multiple models that have been opened together in the viewer or saved as a view. In Docs, issues can only be created against a single model, as multiple models can't be opened together in the Docs viewer.
For this reason, when you open an issue in Model Coordination, you may see a dialog informing you that the models you currently have open are not the same as those that were open when the issue was created, which could lead to missing context. See How can I see what was originally clashing in the issue? for more information.
In addition to the differences around single and multiple model context between Model Coordination and Docs, there are also differences between the types of issues. The most common issue types that you will see when working with Model Coordination and Docs are Design and Coordination/Clash issues. One of the main differences in usage between the two products is that, when you mark a group of clashes as an issue in Model Coordination, the issue type is automatically set to Clash, the clash details are saved with the issue, and the Clashes tab can be accessed on the issue details tab in the Model Coordination viewer. Clash data is not available in Docs, and so creating a clash type issue in Docs is useful for categorizing purposes, but the issue itself is a general issue with no associated clashes.
What can I do with issues in Model Coordination vs Docs?
This table shows the issue actions that you can carry out in Model Coordination, and those that you need to go to Docs to complete.
| Action | Model Coordination | Docs |
|---|---|---|
| Create issues using types and templates |  |
|
| Edit issues | |
|
| Delete issues | |
|
| Search for and filter issues | |
|
| Customize attributes displayed in issues log | |
|
| Open issues in the viewer | |
|
| Export issue reports | |
|
| Restore deleted issues* |  |
|
| Configure issue settings (including types and templates)** | |
|
* Members with at least Manage issue permission only
** Project administrators only
What's the difference between an issue type and a template?
Issue types
Issue types are a way to label your issues, helping you to organize them easily. Types are organized under categories, so you can differentiate between similar issues that relate to different areas of a project. Types have specific fields and field orders associated with them, determining what information is shown or required for an issue using that type.
There are default categories and types, but project administrators can also create custom attributes and types. See the Issue Categories and Types topic for more information.
Issue templates
Issue templates provide a method to efficiently and consistently create issues across a project. Project administrators can create templates to prepopulate information in the issue fields. These templates can then be used by project members when creating issues, meaning they don't have to fill in all fields each time they create an issue. See the Issue Templates topic for more information.
When should I use a type vs a template?
Issue types are useful for defining what fields are included in an individual issue, and also provide a method for easy sorting and filtering of issues.
Issue templates are useful for predefining the information that is added to an issue, making it faster to create issues.
What do the different issue statuses mean?
There are several statuses that can be assigned to an issue in Model Coordination. See the Issue Statuses topic for descriptions of each status and how they can be used in different workflows.
In Model Coordination, the status assigned to a created issue depends on the Type or Template you selected when you created the issue. If you use a:
- Type or Template which has required fields - The status will be set as Draft. You can update the status to Open or keep as Draft when all the required fields are completed.
- Type which doesn't have required fields - The status will be set as Open.
- Template which doesn't have required fields and a predefined status other than Draft or Open - The status will be set as defined in the template. Project administrators can configure which statuses are available in the Issue Statuses Settings page in Docs.
Draft status
Issues with required fields that have not been filled in are automatically assigned as Draft issues. This status can be used to indicate that an issue doesn't yet contain all of the relevant information, and is not ready to be worked on.
Are draft issues visible to other project members?
Yes, Draft issues are still automatically published and can be viewed by members with the relevant permissions.
How do I change an issue status from Draft to Open?
To change an issue from Draft to Open, all of the required fields must be completed. Required fields are marked with an asterisk in the issue details panel.
What are the Location and Location details fields in issues?
Locations can be manually added or imported (including from Revit files) by project administrators, to create a hierarchy of physical locations in your project.
When creating or editing issues, you can select a location from the Location drop-down to associate the issue with that area. If locations have been mapped to areas of the model, the field will be prepopulated based on where you placed the issue pushpin. The Location details field can be used to add any additional information related to that location. This is useful as it is more specific than using the general Description field.