User-defined relationships are a feature in the Modelling Tool that allows for the creation and visualization of indirect relationships between objects by defining custom connections. This is used to manage complex situations where objects are related at multiple levels, for example, when an activity is linked to a role or an application, without these objects having a direct relationship. user-defined relationships are useful for creating matrices, listing relationships between objects, and simplifying the publication of information, particularly when managing many-to-many relationships. The feature requires careful and consistent use to achieve the best possible results and can be applied to examples such as roles in systems, activities in organizations, or meeting participants in an organizational model.
What are user defined relations?
User-defined relationships, or relationships as they are called in the Modelling Tool, are a way to find an object through the relationship of multiple objects.
Let's use the activity as an example. It has a role that performs the activity and an application used by the activity.
Role and application have no direct relation but an indirect one. It is this indirect relationship that we can use user-defined relationships to extract.
To get the maximum benefit from user-defined relationships, it requires consistency in drawing.
However, there are situations that can make this tricky. We call this many-to-many relationships.
For example, if we want to know which individual is responsible for which organizational unit.
Do not model like this!
We have two different units where Lisa and Anders are unit managers.
The problem is that since both Lisa and Anders have the same position, they are both responsible for both units. This is not the case in reality, but for the system, that’s exactly what we’ve stated. A unit manager is the main responsible for two different departments. This will give what we can call false positive results.
So we have many departments and many individuals where an object in the middle is shared by the other objects.
Model like this!
The correct way to draw this is to say production manager and support manager instead of unit manager. They probably have different titles for their positions.
The same approach applies to other roles or positions, such as nurse or process owner.
How are user-defined relationships created?
Marked symbol
This is the starting point for the relationship. It also means the relationship is one-way.
Result
In the gray area, you select which object should be the result.
Relationships and direction
Each row contains the relationship and direction of the relationship. It also specifies which object the relationship for the row is connected to.
OR function
Above the result, there is a symbol to add more cases that the relationship can result in. Ideally, we should not mix different objects as results, but it is fully possible, as we can see in the example below regarding system usage.
Filter
Starting from version 5.5, it is possible to use values from fields as additional restrictions or selections per object on each row.
Use cases for user-defined relationships
Matrices
User-defined relationships can be used in matrices instead of the usual relationships. See the example below.
Note: The Y-axis in matrices represents the marked symbol.
Fields for lists
By creating fields with the relationship field type, the result of the relationship can be displayed in the properties of an object but also as a column in lists. The default is that the marked object should have the field.
Information in publishing
In the publishing profile’s side panel, user-defined relationships can be added for objects. It will only be displayed when the marked symbol is clicked.
Examples of user-defined relationships
Which roles/positions use the system?
If a matrix shows which roles and/or positions use which system, you need the following user-defined relationship. It is based on the role and the application being linked to an activity in the process flow to work with, according to the image, correct relationships.
This is a favorite useful for IT departments or system administrators during training initiatives or system changes.
Using this relation in a matrix with a list of positions and roles, along with a list of applications, will give this result.
Which activities does a position perform (via roles)?
How do I, as a new employee, know which activities are related to my position? This is where this relationship is useful to add. It is best linked in a matrix as a complement to the responsibility matrix or as an additional relation when clicking on a position.
Very useful for new employees and enhances the use of the organizational model.
Which individuals are involved in a meeting?
What meetings do we have, and who should be part of them? If you’ve read the article on meeting mapping, this relationship is a good complement.
This is somewhat of a special case and is based on having individuals in the organizational chart. It also assumes you have different ways of determining who should attend meetings. Is it because of the person’s position, competence/responsibility, or as an individual?
Comments
0 comments
Please sign in to leave a comment.