Best practices in Tekla Model Sharing

Tekla Structures
Tekla Structures
Tekla Model Sharing

Best practices in Tekla Model Sharing

To keep your shared models in good shape and to share your changes successfully, follow the Tekla Model Sharing best practices.

Note that in some situations, pour management has caused conflicts when reading in, even if the pour units have not been modified. These conflicts may result in objects being removed from pour units.

For general Tekla Model Sharing troubleshooting instructions, see Troubleshooting Tekla Model Sharing.

How different object types work in shared models

When several users modify the model at the same time in Tekla Model Sharing , conflicts may occur.

In general, all object types work similarly in Tekla Model Sharing. When you read in, the changes in the incoming packet override your local changes to the same object. In other words, if several users modify the same object, the user who first writes out the changes to the sharing service wins in conflicts.

Before you start to share models, agree on common ways of working.

For example,
  • have users work on different areas of the model.

  • check catalogs so that they include all the needed definitions.

  • check family numbering settings.

    Family numbering settings are shared but cannot be incrementally updated. We recommend that one user first reads in all the packets, makes the updates and then shares the settings by writing them out. If the user needs to read in before writing out, it is important to check that the settings are as they were before starting to share them.

    Give start numbers in wide ranges so that you do not run out of numbers within a numbering series, and that any numbering series does not overlap with another.

    We recommend you to use the Number series of selected objects command on the Drawings & reports tab when numbering.

  • agree whether pours will be used in the model and set XS_​ENABLE_​POUR_​MANAGEMENT accordingly.

    In some situations, pour management has caused conflicts when reading in, even if the pour units have not been modified. These conflicts may result in objects being removed from pour units.

    If the pours are enabled in the model, do not disable the pours using XS_​ENABLE_​POUR_​MANAGEMENT , especially in the middle of the project. The pours and pour breaks in the model and in the drawings may get invalid, and you may lose all pour-related modeling work.

If users modify different properties of the same object, the end result is a combination of modifications.

  • Model objects

    A shared modification to an object property overrides any other object property modification.

    For example, one user modifies a beam profile and writes out. Another user has modified the material of the same beam and reads in. The user who modified the beam material loses the changes, because the shared changes override the local changes to the same object.

  • Grids

    If there is a conflict in sharing grids, grids are recreated using the original values that have been set in the grid properties. Any manually added grid lines are lost.

    For example, when two users modify a grid by adding extra grid lines and write out, the added grid lines disappear from the model when they read in.

  • User-defined attributes (UDAs)

    A shared change to a user-defined attribute (UDA) overrides changes to the same UDA only.

    For example, a change in the Comment UDA overrides a change to the Comment UDA but not to the Shorten UDA.

    A shared change to a part does not override UDA changes and vice versa.

  • Part and the related component

    A shared change to a part does not override component changes and vice versa.

  • Drawings

    There can be duplicate drawings from the same part.

    For example, two users create drawings from the same part when they are working on their local versions of the shared model. When both users write out their changes, two drawings appear on the drawing list. Tekla Structures does not delete either of the drawings, and it does not merge the changes from the drawings. You need to visually check the drawings and decide which drawing to delete, or to use drawing locks to prevent other users modifying the drawings.

  • Pours

    Automatic assignments of objects to pour units are not shared. The Calculate pour units command has to be run to update the pour units.

    • If XS_​CALCULATE_​POUR_​UNITS_​ON_​SHARING is set to TRUE (which is the default value), Tekla Structures automatically calculates and updates the pour units during writing out and reading in.

    • If XS_CALCULATE_POUR_UNITS_ON_SHARING is set to FALSE , each user has to run the Calculate pour units command in their local version of the shared model when they need up-to-date pour unit information.

      For example, user 1 moves a reinforcing bar so that it touches a pour object, runs the Calculate pour units command to add the bar to the pour unit, and writes out. When user 2 reads in, he sees that the reinforcing bar has been moved, but the bar has not been added to the pour unit.

    Manual assignments, and other modifications to pour objects and to the objects attached to the pour objects (such as changes to geometry or location), are shared. A shared manual change in pour unit assignment overrides a local change.

    For example, user 1 adds an embed to a pour unit by using the Add to pour unit command, and writes out. User 2 has added the same embed to another pour unit by using the Add to pour unit command. When user 2 reads in, he sees that the embed has been added to the pour unit user 1 added it to.

  • Standard files for numbering setup

    Standard files for numbering setup are not loaded automatically when you read in. If you want to take them in to use, you need to reload them after reading in.


If an object deletion has been written out to the sharing service, the object will be deleted in your model when you read in. This happens regardless of whether you have modified the object before reading in. Deleted objects remain deleted if the deletion has been shared.

Deleted objects are not visualized when you read in.

How object IDs work in shared models

Tekla Structures objects have an identifier that is shown as an object GUID, Globally Unique Identifier, that is also used in Tekla Model Sharing.

This means that features that do not use GUIDs need to be changed to use GUIDs:

  • Interoperability import/export actions:

    • FabTrol XML

    • ASCII

  • All other applications, macros and report processes that rely on static IDs.

How to share catalog updates without creating new objects

Sometimes you may need to update catalogs with new definitions, such as new profiles, and share the changes without creating any objects with the new definitions.

  1. Ensure that all users on the shared model write out their changes.
  2. Read in all the model changes.
  3. Update the needed catalogs.
  4. Create a new baseline.
  5. Ensure that all users join the created baseline.

    After users have joined the baseline:

    1. Ensure that users check that their settings for excluded files and folders are up-to-date in File > Sharing > Sharing settings > Exclude , or that they copy the FileSharing.ini file from the previous local version of the model in ..\TeklaStructuresModels\<model>\ModelSharing\Settings.
    2. Ensure that users remove their previous local versions of the model.

How to share Organizer data

By default, Organizer data is not shared. However, you can use the Organizer import and export with Tekla Model Sharing to share the Organizer changes.

  1. Select a user who is responsible for the Organizer data. This is User A.
  2. User A creates the Organizer data and exports the data to a model subfolder.

    Note that the selected folder cannot be the default ProjectOrganizer folder.

  3. User A writes out.
  4. User B reads in and notices that there is new data available.
  5. User B opens Organizer and imports the data that User A has exported.

    The data appears as new in Organizer.

  6. User B removes the old Organizer data and saves the model.
  7. User A updates the Organizer data, exports the update and writes out.
  8. User B reads in and imports the updated data to Organizer.

    The data appears as new in Organizer. User B removes the old data.

Backing up shared models

We recommend you to back up the models used in Tekla Model Sharing. In case there are problems with a shared model, it is possible to select any user's local version of the model, or a model that has been backed up, and continue working using that model. Make sure that you have the complete backed up model in use and that the model folder includes, for example, drawings and different databases. This ensures that the model functions properly and you do not lose any data. If the backed up version of the model is old, reading in all the changes may take some time.

Back up your models according to your company conventions, for example, by using Windows Backup. You can also use the File > Save as > Save and create backup copy command to create a backup copy of the model. The backup copy will have the same GUIDs as the original model.

Note that the Save as command cannot be used for backing up the model. If you use Save as , the model gets new IDs and it has no relation to the original model.

If you use the Save as command, the model history is not copied with the saved model.

Restoring shared models

If a shared model has problems that may cause loss of working time, a company administrator can delete the model versions that have problems using Management Console for Tekla Model Sharing. It is also possible that a user of a shared model restores a previous version of the model in Tekla Structures , and that model is used in Tekla Model Sharing.

Management Console for Tekla Model Sharing provides a web-based access for administrators to manage all shared models of an organization. An administrator can lock a model and name one user as the lock owner who can investigate the model in Tekla Structures. Once the lock owner finds the problem, the administrator can delete the model versions that are causing the problem, and then unlock the model so that it can be used normally again.

While the model is locked, the sharing commands in Tekla Structures are available as follows:

  • The Read in and Write out icons have yellow arrows. Only the lock owner can use these commands.
  • On the File menu, the Read in , Write out , Create baseline and Users commands are available for the lock owner.
  • In the Shared models dialog box, the Edit model , Manage users , and Remove model from cloud commands , and joining a particular model are available for the lock owner.

For other users the sharing commands are not available.

If a user of the shared model has already read in or written out any of the model versions that the administrator has deleted, Tekla Structures shows the Write out and Read in icons with red arrows for this user. The sharing commands on the File menu are not available. The user needs to rejoin the model.

If a user is not using any of the deleted versions, the user does not need to rejoin.

Note that it is also possible to revert to an earlier version of the model without further investigating it. The administrator can lock the model in Management Console for Tekla Model Sharing , delete the versions that are not needed or that contain errors, and then unlock the model. After this, the users need to rejoin the valid version of the model.

Note that when model versions are deleted, the changes that have been made in those versions are lost from the model. The changes that should be included in the model need to be made again and read in.

Another option to take a previous version of the model into use is that a user of the shared model performs the following steps:

  1. Join the model again.
  2. Read in the packets until you have reached the preferred level in the model history.
  3. Exclude the model from sharing.
  4. Start sharing and invite other users again to the model.

    Ensure that all the users within the model start to use the restored version of the model.

Rejoin the model if the model is not saved after write out

If there are errors in writing out changes to the sharing service, you may need to rejoin the model. Tekla Structures will show you an error message if the errors in the write out could cause database inconsistencies and corrupt model data.

When you write out, Tekla Model Sharing does the following:

  1. Saves the model.
  2. Prepares the incremental packet. The data in the model folder is not changed yet.
  3. Uploads the incremental packet to the sharing service.
  4. Saves the model again if the incremental packet is uploaded successfully. Local model data is updated with the needed information.

Tekla Structures will not show you an error message if there are errors at any step before step 4. The sharing service has not received the model update yet. You can try to write out again as the model folder does not contain any data that would prevent the write out. If there are new updates available for the model, first read in the updates and then try to write out again.

If there are errors at step 4, Tekla Structures shows you an error message advising you to rejoin the model. After joining, you can check from the sharing history that your write out was uploaded to the sharing service.

Errors at step 4 mean that the model may not have been saved correctly, and model data may be corrupted or lost. The model has several different Tekla Structures databases each of them with their own baseline. If there are errors, the Tekla Structures model does not have all the needed information of what has been shared.

How to get support for sharing issues

You can contact Tekla Structures support to solve Tekla Model Sharing issues.

When you deliver your model to your local support for investigation, ensure that you include the following:

  • The model. Zip the model but do not save it anymore before delivering it.
  • Give Viewer permissions to Tekla Structures support by inviting to the model.

    Remember to remove Tekla Structures support from the users after the model has been investigated.

  • Detailed description of the problem.

    Include steps to reproduce the problem if possible.

  • Images and screenshots.
  • Which Tekla Structures version you are using.
  • Which environment and role you are using.

Was this helpful?