Record Relationships

Record Relationships are the key element that makes data information. They store different types of relationships automatically, but also allow manual relationships to be entered.

• Automatically created links
  • Location of an object in an archive / package
  • Obligation
• Manually created bindings – documentation
  • Linkage
  • Linkage description
  • lock
• What objects can be linked

Only the interdependence between important information allows you to work with information effectively. The option of user-defined relationships allows you to describe the connections that are important for recording the connections as well as maintaining valuable knowledge.

You create the relationships between objects yourself or the system creates them automatically based on your actions.

Automatically created links

Automatically created relationships cannot be edited or deleted by the user, or can be deleted indirectly.

Location of an object in an archive / package

Placing an object in an archive can be done by a person with the permission to create a package. Bindings document in which packages and archives the object is located.

Obligation

A duty bond is between the definition of a sample task and the obligation on which the action must be performed. The relationship is created by the user specifying the obligations for a sample task.

Manually created bindings – documentation

Linkage

A bond between objects is always between two objects. You can create a bond from an object that you are tying towards the other. You can add bindings from an object that you have the right to work with, even to objects that you are not allowed to edit (but you can see them). This is why you always select the object to which the bond leads.

First, the selection will offer you the names of the objects that you can attach. Select an object type from the list (e.g. information) and then you will be given the option to choose what specific object (in our example information) you will actually attach.

Remember: Since you are offered a list of all objects, there can be many. The system will always load a limited number of objects for you, so be sure to use the filters in the list header to select the correct object.

Linkage description

A bond by itself is usually not enough to clearly express why it exists. At the very least, it must be named. Additional information items are optional, but we recommend creating rules on how many bindings to describe.

Binding types are described in more detail here.

Name you can enter any name. However, it is advisable to use standard names to allow quick orientation. Therefore, it is possible to select a name from the list of standard names. This list is managed by your administrators and you can therefore easily agree to extend it.

Description A longer description on a separate page is usually filled in if an internal methodology is required. If not, we recommend not using a long description, because without defined rules on when and what to use the description for, it is likely that users will not notice the content because they do not even assume it for the binding.

Version A version of the binding is used if you propose changes and plan to develop the model in the system in versions.

lock

A lock prevents editing the binding. If you want to change the binding with a lock, you must first unlock the lock.
Reminder: If the binding was created by the system, it is not possible to unlock it.

What objects can be linked

The system limits what objects can be linked to which to help maintain order in the bindings. This is important so that the relationships are recorded in the right places.
Important note: You may find that you would need to bind a different type of object to the object than the system allows. Contact your system administrator, the allowed bindings can be expanded – if the proposed binding makes sense, there is no reason not to allow it