Skip to main content
Versioning diagram hierarchies

Publishing diagrams in the hierarchy and avoiding broken hierarchies (pending diagrams)

Updated over 2 years ago

There are certain rules to versioning diagrams in the hierarchy. In order to ensure your diagrams are versioned correctly, you need to understand the diagram version architecture and hierarchy rules.

Article outline

  • Prerequisites

  • Diagram and diagram versions

  • How hierarchy works

  • Versioning diagrams in the hierarchy

  • When versioning breaks the hierarchy

  • You might be also interested in

Prerequisites

  • Map owner or Editor rights on a map

Diagram and diagram versions

Each diagram has its unique ID. You can actually see the diagram ID in the URL address when you open a diagram. It is the string of number and letters highlighted in the image below.

Each diagram can have multiple versions. A diagram version contains boxes, lines, sticky notes and all other content.

How hierarchy works

A diagram hierarchy exists within a single map and is created when you create a child diagram for an activity box. The diagram in which the child diagram was created becomes the 'parent'. The diagram that was created becomes 'the child'.

The level numbers of diagrams denote their place in the map hierarchy in a particular version. These numbers are based on box numbers on the parent diagram, from which child diagrams were created. So a child diagram created from box 1 in the top level diagram becomes diagram 1.1, a child diagram created from box 2 becomes 1.2 etc.

The diagrams in the hierarchy relate to each other through unique diagram IDs. In other words, if we look at the example below, when you navigate around the map hierarchy, you are opening a specific diagram by ID.

Versioning diagrams in the hierarchy

Once you have published your map, you can change and version manage any child diagram in that hierarchy. If you want to apply changes to just one diagram, you can change and publish only that one diagram.

While you publish only that one diagram, the system will automatically update the published version of the entire map (and all its diagrams). This is because the system captures what was the state of the entire hierarchy at the time of the release.

In the example below, you can see a published diagram in the hierarchy and how its version was updated multiple times due to other diagrams in the map being changed.

Which leads to another key rule in versioning logic: the diagrams in the hierarchy relate to each other through unique diagram IDs AND are based on the map version.

When versioning breaks the hierarchy

Let's imagine you have a diagram hierarchy shown above, and you published all 4 diagrams (parent and its 3 children). Then, in the draft version of the map, you delete the previous child diagram and either create or import a new child diagram.

If you were to publish just the new child diagram without the parent diagram, you will break the hierarchy.

The reason is that the published parent diagram still points to diagram ID Bbbbb which no longer exists. The published child diagram Eeeee has no relationship to the published parent diagram and does not know its place in the map hierarchy. Hence, why the diagram will be displayed as 'pending' - because the system cannot calculate the hierarchy number.

Publishing the parent diagram which now points to the new diagram, Eeeee will resolve this issue and fix the hierarchy.

You can also break the hierarchy when you publish the children diagrams for the first time without publishing the parent diagram. That is why we recommend you always publish the parent diagram first.

Broken hierarchies are not necessarily problematic. If you embed your diagrams in other webpages, you might not even experience any issues. But navigation within a map will be affected.

You might be also interested in

Did this answer your question?