When working together on model packages and projects, users edit models in these packages and projects. While working, users are continuously connected to Horizzon. The changes users commit are immediately synchronized and can directly be processed by the other contributing users. Before changes are committed, the elements users work on in a model are claimed the moment they touch them. This affects the operations other users can perform on these elements. 

Claimed data

When a user starts editing a model in a shared model package or project, only the elements that are edited are automatically claimed. Other contributing users cannot, or have limited options to edit these elements. This limitation of editing applies when users are working on the same model package or project, but also between a master model package and associated projects. If one user is claiming an object in a project, then the same object in the project's master model package is also claimed, and cannot or limited be edited by others. It also works the other way around: claimed objects in a master model package are also claimed in the projects based on this model package.

Basically, all elements in a model are claimed individually, except for views and diagrams. If a user is editing a view or diagram, which often contains multiple elements, other users cannot make visual changes to it like moving, removing and adding elements. Renaming elements remains possible.

Metrics are a special case. When adding metric values to an object, not the object getting the values is claimed, but the metric object.

Below are a few examples to illustrate the possibilities and limitations of editing a claimed object.


If one user moves an object within the model, this object is claimed. Other users cannot remove, rename or move the claimed object.

If one user removes an object from the model, this object is claimed. Other users cannot edit this claimed object at all; they cannot remove or rename it, or link any relations to the object.

If one user creates a relation between two objects, the objects are claimed. Other users cannot remove these claimed objects but can rename them or move them within the model.

Collaboration conflicts

If a user tries to perform an action that is not allowed on a claimed element, a message will appear in the Messages window addressing a collaboration conflict. Generally, only the same type of editing generates a conflict, for example, renaming an object by one user and renaming the same object by another user, or moving/resizing the same object. For examples of collaboration conflicts, please refer to Team Platform troubleshooting.

Example of a collaboration conflict message

Editing offline

If a user chooses to edit a model offline when working together, the user can safely edit the model offline without being overruled by other users' changes to the model. Any claims done by the other users are affected by the offline edited model. Any claims already made by the other users before the model is taken offline, remain active with the users who have made the claims.

The other users will not see the changes of offline editing in their model browser until their Activity Console has been synchronized.

Editing models offline is only possible when working with a locally installed Enterprise Studio (on-premise or hybrid solution), it does not apply to the cloud solution Enterprise Studio Online.

Read-only objects

When working together, objects in a model package may be read-only because they are in a model that is read-only to you (for example in a project). You cannot change these read-only objects, but it is still possible to create relations between them.

When creating relations between read-only objects, take note that it has an effect on the location where the relations are stored. By default, a relation is stored in the layer that contains the "from" object. If this layer's model is read-only, the relation is stored in the layer that contains the "to" object. When the "to" model is read-only also, the relation is stored with the view it was drawn on.

As a result, relations are no longer relocated when their "from" object is moved: after creation, the relation stays in the same location until explicitly moved by the user.