Sync Tool
The Sync Tool is an add-on that synchronizes selected entities between different inorigo® instances – for example, to promote model changes from development to test to production.
Overview
The Sync Tool synchronizes selected entities across inorigo® instances by creating and merging pull requests. You collect the entities to move in a pull request, review what merging it would change, and merge it.
Note that a pull request in the Sync Tool is not a git pull request: it is a set of inorigo® entities to synchronize from one instance to another.
The Sync Tool is available in the launcher menu, in the toolbar, or as a card in Workbench.

The Sync Tool's pull request list, with a draft and a merged pull request created by other users
Before you start
The Sync Tool only works when all of these are true. Each one is explained further down.
- The Sync Tool plugin is installed on both instances, in the same version. See Data Context.
- The target accepts the source. An administrator adds the source to the target's sources in System Management. See Source & Target.
- You are logged in to both instances, and the source is set up to send you back to the target after you log in. See Logging in to the source.
- Both instances have the same built-in relation types. The Sync Tool compares the IDs of the built-in relation types classifies, implements, contains, and consist of in the two instances, and will not open a pull request when they differ. See Data Context.
You also need these rights:
- Read on the entities you synchronize, in both the source and the target.
- Write in the target. Creating a pull request requires write access to Generic Data Objects, because a pull request is stored as one. Merging requires write access to every entity the merge changes in the target.
A merge cannot be undone. Review what it will change before you merge. See Review Dialog.
Syncing changes, step by step
From a new pull request to a merged one, the Sync Tool takes you through these steps:
- Open the Sync Tool on the target instance, press New pull request, choose the source, and press Create. See Sync Setup.
- Find the entities that have changed in the source, in the Source Panel.
- Check how each one differs, with its state, the Details panel, and the Attributes panel.
- Add the ones to synchronize to the Pull Request Stage.
- Clear every red badge, usually with Resolve all. See Resolving dependencies.
- Write a comment, and save if you want to come back to the pull request later.
- Open the Review Dialog and check what merging will change.
- Merge, with a comment.
- Update by hand what does not travel. See After merging.
Source & Target
Pull requests have a Source Instance and a Target Instance.
- The Source Instance is the instance the entities come from.
- The Target Instance is always the inorigo® instance from where you launched the Sync Tool. The pull requests are stored there.
- The available Source Instances are the ones the target accepts. They are set up in System Management by an administrator.
When merging a pull request, inorigo® syncs the selected entities from the Source to the Target Instance. Depending on their state, they will either be created, updated, or deleted. See Entity states.
Data Context
The Sync Tool uses the current Data Context of the target instance and the Data Context to which you are logged in on the source.
A pull request remembers both Data Contexts, and the IDs of both instances. If you open it later and any of them has changed, the Sync Tool shows Environment mismatch detected instead of the pull request. It does the same when:
- the two instances run different versions of the Sync Tool plugin, or
- their built-in relation types classifies, implements, contains, and consist of have different IDs. The dialog shows this as Hard code matching: No.
The dialog has a table with the saved and the current Data Context, the plugin version, and the instance ID of the source and the target, so you can see which one differs.
Logging in to the source
You have to be logged in to the Source Instance to sync from it. When you open a pull request, the Sync Tool checks this:
- Not logged in: the Sync Tool shows You are currently not logged in at the source instance. Log in takes you to the source's login page, and back to the Sync Tool after you have logged in. Close closes the pull request.
- No answer from the source: the Sync Tool shows The source cannot be reached. Try to connect checks again. Close closes the pull request.

You are asked to log in when you are not logged in to the Source Instance

The message shown when the Source Instance does not answer
Note: The Source Instance only redirects to hosts listed in its redirect white list (inorigo/settings/redirect-whitelist.txt). An administrator must add the Target Instance's host name to it. Otherwise the Source cannot redirect you back after login, and you cannot log in to it from the Sync Tool.
Considerations for Data Connections and Data Sources
Not everything travels. Before syncing, review any Data Connections and Data Sources that reference paths or URLs tied to a specific server environment. Two common cases require attention:
- Environment-specific Connections — a Connection pointing to a base URL or file system path specific to the source environment (for example,
https://factory.floor.test) will not resolve correctly on the target. Since multiple Data Sources may share the same Connection, a single misconfigured Connection can break all dependent Data Sources at once.
- Local file paths — Connections or Data Sources referencing local file system paths (for example,
C:\data\or/var/data/) will break on the target instance if the same path does not exist in that environment.
inorigo® provides dynamic Import/Export connections to help manage environment differences automatically. However, custom folder connections and manually configured Connections are not covered by this and must be reviewed and updated manually after syncing.
Pull Request Overview
The Pull Request Overview lists the pull requests stored on the Target Instance. The dropdown at the top limits the list to one state (All, Draft, Merged, or Failed), and you can toggle between all pull requests and just the ones you created (My pull requests). When no pull request matches, the list shows No pull requests and Create one or change filter.

A merged pull request in the Pull Request Overview

My pull requests shows only the pull requests you created
State
Pull requests can have the following states:
Draft: Created but not yet merged. You can view all drafts, but you can only edit and delete the ones you created.
Merged: Synchronized successfully. You can open and review a merged pull request, but you cannot edit or delete it.
Failed: The merge failed for some reason. You can open and review a failed pull request, but you cannot edit or delete it.
Changed: Earlier versions of this page said that you could delete failed pull requests that you created. In the current version, only drafts can be deleted.
Pull Request Properties
| Column | Shows |
|---|---|
| State | The state of the pull request, as a tag |
| Date | When the pull request was last saved or merged |
| Comments | A preview of the comment attached to the pull request. Clicking the comment, or its |
| Source | The name of the Source Instance |
| Submitter | The name and email of the person who created the pull request |
| Actions | Delete, Edit or Open, and Review, as described below |
Delete: Deletes the pull request, after you confirm. You can only delete drafts that you have created.
Edit: Opens a draft that you have created, so that you can change it.
Open: Opens the pull request in read-only mode. Pull requests are read-only when they were created by another user, or are merged or failed.
Review: Opens the Review Dialog to review the outcome of a pull request. You can merge your own draft pull requests from the Review Dialog.

Clicking a comment in the list opens the whole comment

Delete asks you to confirm before a draft is deleted

Someone else's draft offers Open instead of Edit, and cannot be deleted
New Pull Request
To create a new pull request, press New pull request in the toolbar.
Sync Setup
The Sync Setup dialog asks for the Source URL, from the dropdown of sources the target accepts. The Target URL is the instance you are on. The available sources are administered by an administrator through System Management. Create opens the new pull request in the editor. The pull request is not stored until you save it.

The Sync Setup dialog
If you are not logged in to the source, the editor asks you to log in once the pull request is open. See Logging in to the source.
Edit Pull Request Overview
The Edit Pull Request view consists of a toolbar and four panels: Source, Pull Request Stage, Details, and Attributes. The panels are resizable and can be toggled from the toolbar.

A new pull request in the Edit Pull Request view
The Toolbar

From left to right:
1. Back Arrow: Closes the pull request and returns to the Pull Request Overview. If there are any unsaved changes, you will be asked first, as described below.
2. Pull Request Info: Displays the Source and Target inorigo® Instance.
3. Revert: Undoes all changes made up until the last save.
4. Save: Saves the pull request as a draft.
5. Delete: Deletes the current pull request and closes the view. You will be prompted to confirm the deletion.
6. Review: Opens the Review Dialog, where you inspect the result of the pull request and merge it. It is disabled until at least one entity is staged.
7. Comment: Opens the comment dialog.
8. Source: Shows or hides the Source Panel.
9. Stage: Shows or hides the Pull Request Stage.
10. Details: Shows or hides the Details panel.
11. Attributes: Shows or hides the Attributes panel.
Revert, Save, and Delete are disabled while there is nothing for them to do, and on a pull request you are not allowed to edit. The launcher, information, and account menus at the right end are the same as in every inorigo® web module.
With unsaved changes, the Back Arrow opens the Unsaved changes dialog: Save & Close saves the pull request and closes it, Discard Changes closes it without saving, and Cancel keeps it open.

The Unsaved changes dialog
Source Panel
The Source Panel is where you search for and select the entities to include in the pull request. It consists of two sections. The upper part is a Filter, and the lower part is the Result Table.

The Source Panel with the Filter and the Result Table
Filter
Use the filter section to find the entities that you want to add to your pull request. The filter finds entities changed in the source within a time span, from the source's transaction history.
Note: To mitigate the time required to search the whole inorigo® database, the filter section is pre-populated to narrow the scope from the start. The maximum From and To time span is limited to 12 months for the same reason.
You can collapse the filter section, with the arrow at the right of Filter at the top, to make more room for the Result Table.

The filter folded away, leaving more room for the Result Table
Group: Allows you to select an Entity Group of the source. Groups used for authorization, of users or of entities, are not offered. Selecting a group clears From, To, and Data Type. The Result Table then lists the members of the group that have a transaction of the kinds ticked under Quick Filters (Created, Deleted, Updated), of any age and any data type. Clearing the group restores the defaults: the last three months, and Definition Node.
From: Specifies the earliest date to look for any transaction. By default, From is set to three months ago. The earlier the date, the more data inorigo® must process. Depending on the other filters and the number of entities, this can take a long time.
To: Specifies the last date to look for transactions. By default, this is today's date.
Data Type: Lets you specify which type of entity you are interested in. By default, the data type is set to Definition Node. The menu groups the data types; Definition Node and Instance Node are found under Generic Model. Choosing Instance Node lists the Instance Nodes that have changed instead. As in Metagraph Builder, the menu is configured on each inorigo® instance, so yours may look different from the screenshot.
Create filter: The button next to Data Type opens the Query Editor, where you can create a more advanced filter, in the same way as when filtering the Library in Metagraph Builder. When a query is active, it is summarized as a string in the filter. You can clear the filter by clicking the X next to it, Clear filter.
Search: Lets you filter on an entity name.
Quick Filters: The checkboxes let you quickly filter the result list on transactions: Created, Deleted, or Updated. While a query from Create filter is active, Deleted is disabled, because you cannot filter on deleted entities.

Searching the Source Panel by name

The Data Type menu, with the Generic Model group open. The menu on your instance may look different.

With Instance Node chosen, the Result Table lists the Instance Nodes that have changed in the source
From must be earlier than To, and at most 12 months before it. Otherwise the dates are refused with the message The filter time interval is invalid. Maximum is 12 months., and the Result Table keeps the results for the previous dates.
Note that though similar, the quick filters are not 1:1 with the states in the Result Table. The quick filters apply to transactions in the source, while the states show differences between the source and the target. For example, an entity created in the source may well exist in the target already.
Changed: By default, From is now set to three months ago (previously one month), and the maximum time span is 12 months (previously six months).
Result Table
The Result Table lists all entities matching the filter in alphabetical order in a tree list. The arrow in front of an entity expands it, so you can see its values and references. Clicking an entity shows it in the Details and Attributes panels.
To add an entity to the pull request, hover over it and press the ⊕ icon in front of it. The entity is added to the Pull Request Stage. To remove it, press the ⊖ icon in either the Result Table or the Pull Request Stage. The ⊕ and ⊖ work like a checkbox: a staged entity shows ⊖ in front of it, in both the Result Table and the stage.
Entity states
Each entity in the Result Table is tagged with a state, which shows how it compares between the Source and the Target Instance. Hover over the tag for an explanation. For DIFFING, the tooltip also lists what differs.
| State | The entity… | Merging it… |
|---|---|---|
| NEW | exists only in the Source Instance | syncs the new entity to the target |
| DIFFING | exists in both instances, but differs | overwrites the target with the source |
| MATCHING | is identical in both instances, and so is everything related to it | changes nothing. No need to synchronize |
| INDIRECT | is identical, but entities related to it differ | changes nothing on the entity itself |
| DELETED | has been deleted in the Source Instance | deletes it from the target |
| MISSING | exists only in the Target Instance | deletes it from the target |
| CONFLICT | has been deleted in the Target Instance | cannot be done. You will not be able to merge this entity |
| ERROR | could not be compared, for example because you are not allowed to read it | cannot be done |

The tooltip on a DIFFING state lists what differs between the source and the target

The tooltip on an INDIRECT state: the entity is identical, but entities related to it differ

The tooltip on a NEW state: the entity exists only in the source

A DELETED state on an entity that has been deleted in the source
An entity that only the target has, or one the target has deleted, has not changed in the source, so the filter does not find it. Its state shows further down instead: below an entity in the tree, or among a staged entity's dependents in the Pull Request Stage.

A CONFLICT state on an Instance Node that has been deleted in the target, shown below its Definition Node in the tree

A MISSING state on an entity that only the target has, among a staged entity's dependents
Changed: The states INDIRECT, MISSING, and ERROR are new. Restricted is no longer a state; restricted entities are now marked with a lock in the Pull Request Stage. See Restricted entities.
Pull Request Stage
The Pull Request Stage shows all entities currently included in the pull request. The total number of entities in the pull request is shown in parentheses in the title.
- Add an entity by pressing ⊕ in front of it in the Source Panel. It is added at the end of the stage.
- Remove it by pressing ⊖, in the Source Panel or in the stage.
The Pull Request Stage lists the entities in the order they were added, in a tree list. Entities are tagged with the same states as in the Result Table.

An entity added to the Pull Request Stage, with a red and a yellow badge
Dependencies & Dependents
An entity may depend on other entities: a Definition Node on its superclass, a relation on both its ends, an Instance Node on its Definition Node. Those are its dependencies. The entities that depend on it are its dependents. Some dependencies are required for it to function (for example, a superclass), while others are optional (for example, icons).
- To synchronize an entity, its required dependencies must also be included in the pull request, unless the target already has them as they are. Note that an entity that is a dependency may itself have dependencies!
- Its dependents do not have to be included. The exception is a deletion: deleting an entity deletes its relations as well, so everything that depends on an entity being deleted must be staged together with it.
Changed: Earlier versions of this page said that all required dependencies and dependents must be included. Dependents are now only required when the entity is being deleted.
A row in the stage shows what it still needs with two badges:
| Badge | Counts | Means |
|---|---|---|
| Red | Required dependencies that are not staged and not already in the target, or the dependents of an entity being deleted | Not ready to sync. The pull request cannot be merged like this |
| Yellow | Other related entities that differ | Related entities differ. The entity can be synchronized without them |

The tooltip on a red badge: a required dependency is not staged

The tooltip on a yellow badge: related entities differ
Staging a related entity takes it off the badge. So a row's state can change, for example from INDIRECT to MATCHING, when you stage something else.
Resolving dependencies
Click a badge to open its menu:
- Show in the list expands the row and opens the groups that hold the entities the badge counts.
- Resolve all stages them, together with what they in turn require, one level down. Anything deeper shows as a red badge on the newly staged rows, to resolve in turn. A message says how many entities were added.

The badge menu

Show in the list expands the row and shows the required dependency

After Resolve all, the required dependency is staged
An expanded row groups its related entities as Required dependencies, Optional dependencies, Optional dependents, and Required dependents. To resolve an entity's dependencies by hand, expand the row and press ⊕ on the Required dependencies or Required dependents group to add all of them to the stage. You can also add entities one by one. You can add optional dependencies the same way, and remove a whole group with its ⊖.
An entity that exists only in the target is never staged without asking. Staging a MISSING entity deletes it from the target, and it may have been created there on purpose. So when Resolve all, or adding a whole group, would stage one, the Sync Tool lists them and asks: Stage for deletion, Leave it out (or Leave them out), or Cancel. Adding a single MISSING entity on its own does not ask; its tooltip says that syncing deletes it.

The Sync Tool asks before staging an entity that exists only in the target for deletion

An entity deleted in the source, staged together with the relation that goes with it
Changed: Dependencies are no longer shown with a warning icon labelled "Dependency". They are now shown as the red and yellow badges described above, with Show in the list and Resolve all.
Restricted entities
A lock in the row means the Sync Tool is not allowed to synchronize that entity. Some kinds of entity are never synchronized, for example inorigo® users, user groups, and system types. Neither is an entity that the target does not let you change. Any change to a restricted entity has to be made in the target by other means. A restricted entity that would change the target blocks the merge.

The lock on an entity that the target does not let you change
Details
The Details panel facilitates reviewing and comparing entities, similar to the Details panel in Metagraph Builder.

The Details panel shows the selected entity in the source and in the target, side by side
The Details panel shows the values of the selected entity in both the Source and Target Instances, side by side in a split view. It has the same tabs as the Details panel in Metagraph Builder:
- The General tab displays primitive values such as name, icon, and description.
- The Attributes tab displays all attributes for the selected entity in a table. It has the same functionality as the Attributes panel, but its layout is vertical.
- The Constraints tab, for an entity that has constraints, shows its constraints.
- The Tree tab lets you explore the structure of the selected entity in a recursive tree.
- The Relations tab lists all relations and possible relations for the selected entity.
- The History tab lists all transactions for the selected entity in a timeline, with dates and timestamps. It also displays the user who committed the transaction and any comments associated with it.
Each side is half as wide as the panel, so the tabs do not all fit: scroll the tab strip sideways to reach the rest.
Attributes
The Attributes panel shows the selected entity's attribute table in the source and, below it, in the target. It mirrors the Attributes tab in the Details panel, but displays the tables horizontally, which can make it easier to overview, especially when comparing many columns.

The Attributes panel compares the attributes of the selected entity in the source and in the target
Comment
Clicking Comment in the toolbar opens a dialog to write a comment for the pull request. You can write it before anything is staged. Save in the dialog closes it and keeps the comment as an unsaved change: it is stored when you press Save in the toolbar. A stored comment is visible in the Pull Request Overview. It is automatically transferred between the Edit Pull Request view and the Review Dialog, and filled in when you merge.
Adding a comment is a mandatory step to merge the pull request. However, you can save a pull request as a draft without a comment.

The comment dialog
Saving a pull request
Save stores the pull request on the target as a draft, with what is staged and its comment. A pull request is ordinary inorigo® data: one entity on the target that holds the whole pull request.

After saving, Revert and Save are disabled until you change the pull request again

A saved draft in the Pull Request Overview
Review Dialog
Review is a mandatory step before merging a pull request. You can open the Review Dialog by either clicking Review in the Pull Request Overview, or Review in the toolbar of the Edit Pull Request view.

The Review Dialog
The current state of the pull request is shown in the title as a tag (Draft, Merged, Failed).
To merge a pull request, you must always do so from the Review Dialog. It serves as a mandatory checkpoint where you examine the expected result of the merge before it is executed.
Once a pull request has been merged, you can open the Review Dialog to examine the result. A merged pull request opens with the Log and the comment only.
The Review Dialog consists of several panels that can be toggled from its toolbar: Log, Pull Request Stage, Details, and Comment.
Log Panel
Similar to the Log panel in Metagraph Builder, the Log summarizes the number of actions that will be committed when merging, and any problems. You can expand the log to see the details.
Unsaved
The Unsaved tab lists all unsaved changes to the model that are ready to be committed. The left column shows a status icon to help identify the change. You can click the icon to the right of the list item to open it in a dialog.
Unresolved issue: You will not be able to commit until it is resolved. This is typically caused by a faulty or missing mandatory attribute value. To fix the problem, you might have to open Metagraph Builder and edit the entity.
Updated: Indicates that the entity will be updated when merged.
Deleted: Indicates that the entity will be deleted when merged.
Created: Indicates that the new entity will be created when merged.
Actions
The Actions tab lists all pending actions that will be performed when merging, shown chronologically in a timeline. It also shows details about the action about to be committed.
The log timeline colors help quickly identify the type of action to be committed.
A blue circle behind the icon indicates that an entity will be created.
A yellow circle behind the icon indicates that a value will be changed.
A red circle behind the icon indicates that an entity will be deleted.
Pull Request Stage
The Pull Request Stage mirrors the Pull Request Stage in the Edit Pull Request view. The title shows the number of entities in parentheses. It provides an overview of all entities included in the pull request, together with their state, such as NEW, DIFFING, or DELETED. Nothing can be added or removed here.
Clicking an entity in the stage opens it in the Details panel.
A red ! marks an entity that blocks the merge. Hover over it to see the reasons.

The red ! on an entity that the Sync Tool is not allowed to synchronize, but that has changes
Details Panel
The Details panel in the Review Dialog displays the selected entity's before and after state in the Target Instance: as it is now, under current version, and as it will be after the merge, under merged results.

The Details panel shows the entity in the target before and after the merge
The General tab displays primitive values such as name, icon, and description.
The Attributes tab displays all attributes for the selected entity in a table. It has the same functionality as the Attributes panel, but its layout is vertical.
The Constraints tab, for an entity that has constraints, shows its constraints.
The Tree tab lets you explore the structure of the selected entity in a recursive tree.
The Relations tab lists all relations and possible relations for the selected entity.
The History tab lists all transactions for the selected entity in a timeline, with dates and timestamps. It also displays the user who committed the transaction and any associated comments.
Merging a Pull Request
To merge the pull request, press the Merge button in the bottom right corner of the Review Dialog. A confirmation dialog, the merge dialog, opens. If there are any errors or dependencies in the pull request, you will be asked to address those before you can proceed with the merge. You must also provide a comment. The dialog first checks the pull request, and the merge cannot go ahead while there is something to fix:
- an entity is CONFLICT or ERROR,
- a restricted entity would change,
- required dependencies are not staged, or an entity being deleted still has dependents,
- a value is missing or wrong, as the Log shows,
- the target's own check of the merge, run without saving, fails,
- you did not create the pull request, it is not a draft, or it has nothing to merge.
Once there are no conflicts or errors in the pull request, the dialog asks for a comment, and the Merge button becomes active when you have entered one.

The merge is refused: a restricted entity would change
Note that you may only merge pull requests that you have created. When reviewing someone else's pull request, or a pull request that has already been merged, the Merge button is not available. See Messages and what to do for how to resolve each problem.
Comment
It is mandatory to add a comment before merging. This is to distinguish between the different pull requests in the Pull Request Overview, and to keep a record of all changes made. Any comment written in the Edit Pull Request view is already filled in. Merge stays disabled until there is a comment. The comment is recorded in the target's history, together with every change the merge makes. See Comment.

The merge dialog with a comment

The pull request has been merged
After merging
The pull request is now Merged. The merge cannot be undone, and the pull request cannot be changed, but it can still be opened from the Pull Request Overview:
- Review shows the Log of what the merge committed, and the comment.
- Open shows it in the Edit Pull Request view, read-only: entities can no longer be added or removed, and Revert, Save, and Delete are disabled. The states compare the two instances as they are now, so a synchronized entity shows MATCHING unless something has changed since. A deleted entity is in neither instance any more, and is shown by its ID, struck through.

A merged pull request in the Review Dialog

A merged pull request opened read-only
Some things do not travel and have to be updated in the target by hand. See Considerations for Data Connections and Data Sources.
Messages and what to do
When opening a pull request
| Message | What to do |
|---|---|
| You are currently not logged in at the source instance | Click Log in. See Logging in to the source |
| The source cannot be reached. | Check that the source is running and that you can open it, then click Try to connect |
| Environment mismatch detected | Find the row that differs in the dialog's table. See Data Context |
In the Source Panel
| Message | What to do |
|---|---|
| The filter time interval is invalid. Maximum is 12 months. | Make From earlier than To, and at most 12 months before it |
When merging
The merge dialog shows one of these messages instead of asking for a comment:
| Message | What to do |
|---|---|
| There are errors that need to be addressed before merging. Fix them in the Pull Request Editor. | Fix each reason listed under it, as in the next table |
| There are validation errors in the pull request. See the errors in the Log panel. | Open the Log in the Review Dialog for the values that are missing or wrong |
| The dry run check failed. Please review the errors and fix them before merging. | The target refused the merge when it was tried without saving. The target's answer is shown under the message |
| You do not have permissions to merge this pull request. | Only the person who created a pull request can merge it, and only when the target lets them change it |
| The pull request is not in a mergeable state. | Only a draft can be merged |
| There are no changes to merge. | Nothing staged would change the target |
The reasons listed under the first message:
| Reason | What to do |
|---|---|
| The entity has been deleted in the target. It cannot be synced. | Remove the CONFLICT entity from the stage |
| An entity could not be compared between source and target, so it cannot be synced. | Remove the ERROR entity from the stage, or have its rights changed so that you can read it |
| An entity the Sync Tool is not allowed to sync has changes. They have to be made in the target by other means. | Remove the entity with the lock from the stage, and make the change in the target directly |
| Required dependencies are not staged. Add them to the Pull Request Stage. | Clear the red badges, for example with Resolve all |
| An entity being deleted still has entities in the target that depend on it. Stage them for deletion too, or leave the entity out. | Clear the red badge on the entity being deleted, or remove it from the stage |
If the merge itself fails, the merge dialog shows An error occurred during the merge process., with the target's answer below it. The pull request is saved before the merge starts, so what you staged and your comment are kept.
© 2026 Inorigo AB. All rights reserved.