Meta Model Configuration

Overview

This section gives you several options for basic and advanced configurations of your Fact Sheets. As an overview, you will see the ten different Fact Sheet types and their description and the defined renewal periods for the Quality Seals.

Here is the default color representation of the Fact Sheet types:

To adjust the Fact Sheet type color:

1. Navigate to the Administration area. Click the Meta Model Configuration. Locate and click on the Fact Sheet you want to change.
2. Click Edit at the top right corner of the page to open a panel on the right.
3. On the panel, click on Color.
4. Click on the RGB button to cycle the color selection until you find the HEX value.
5. Enter the HEX value as shown above.

Fact Sheet settings

Clicking one of the Fact Sheet types will lead you to the Meta Model Configuration, where you can adapt the configurations of the Fact Sheet type.

On this page, you can see every section of your Fact Sheet. You can select those sections by hovering on the specific area, allowing you to select the respective section easily. Once you select a section, you will see the configuration panel on the right side of the page. In that panel, you can adjust and configure the Fact Sheet.

You can also access the Fact Sheet settings from a Fact Sheet. To do this, go to the More actions menu in any Fact Sheet of the type you want to configure (see screenshot), and select Configuration.

Fact Sheet Name

In the Fact Sheet Name section, you have 4 options to choose from:

1. Configuration

You can adjust the color of the Fact Sheets, the Maximal Hierarchy Level, and the settings for On-the-fly creation. If you enable "On-the-fly" creation, you can create new Fact Sheets, as you want to add new relationships and the related Fact Sheet is not yet available.

2. Manage Translation

Admins can alter individual fields by default and customize Fact Sheets based on the preferred languages of their users. Non-admins can also select for themselves which language to operate in LeanIX overall. There are 5 languages available: English, German, Spanish, French, and Portuguese. This feature is intended to make the tool more accessible and increase its speed of adoption within global operations. In this panel, you can also define what to call a certain Fact Sheet in Singular form or Plural form.

3. Facets Configuration

On this panel, you can select and define which facets you wish to show by default for this Fact Sheet type in the inventory filter sidebar. Once users configure their own facets via the "Manage Facets" option in the inventory, they will only see those personalized custom facets until they select "Reset to default" again.

4. Completion Weights

The Completion weights in Fact Sheet settings will help you adapt the Fact Sheets Types that will help you stay focused on quality management and contribution of new data in Fact Sheets.

Adjusting the weights enables you to adapt the weight of an attribute. The higher the date, the more it will be counted toward completing the Fact Sheet. If the value is set to "0" the attribute will not be counted as completion, and the attribute will be marked with "optional" on the Fact Sheet.

📘

Information

You can check out the detailed information on the Completion Weights on the Completion weights impact on completion score documentation.

Fact Sheet body configuration

By performing similar actions as before, you can now quickly adjust each section of the Fact Sheet in detail.
You can toggle the visibility of certain portions of the Fact Sheet:

Add or remove subsections

You can quickly add or remove subsections by selecting a section and clicking on the + Add subsection button.

Create or remove relations

Creating relations

In addition to creating regular subsections, you can create new relations by clicking the + Add relation button. You are then able to configure the relation based on the following attributes:

• Target Fact Sheet type: Dropdown with all available Fact Sheet types on your workspace.
• Multiplicity: Allows you to define the cardinality of the relation, e.g., “Many to Many” or “Many to One”.
• The section in target Fact Sheet type: Allows you to define which section of the target Fact Sheet type the relation should be visible.

When creating an additional relation to an already related Fact Sheet type, one more attribute is required:

• Descriptor: This allows you to provide a unique identifier to differentiate between the already existing relation and the new relation.

Self-Referencing relations

It is possible to create self-referencing relations, allowing a Fact Sheet type to establish relationships with itself. This unique feature enables a wide range of use cases within your workspace.

Self-referencing relations behave the same way as regular relations between Fact Sheets, except the fact that both ends of the relation target the same Fact Sheet type. Two subsections are created on a Fact Sheet, when creating a self-referencing relation to represent both ends of the relation. This leads to a limitation that only one end of the self-referencing relation is editable, while another end will only reflect changes. This enables you to:

• create & manage self-referencing relations,
• create & manage fields on self-referencing relations,
• move self-referencing relations subsections independently within a factsheet

This unlocks further improvements, such as relations on the same Fact Sheet type, between different subtypes. Example: Relation between Application to Microservice Application. Which is a key component of our Meta Model.

To create a self-reference in a relation, follow these steps:

1. Select the Same Fact Sheet as target. Choose the same Fact Sheet as the target for the relation.
2. Provide two Descriptors. Identify the relation from both directions by providing two descriptors.
3. Creating Subsections. Self-referencing relation creates two new subsections on a Fact Sheet, representing both ends of the relations. Subsections have translations prefixed with provided descriptors.
4. Independent Translations. Translations for these subsections can be changed independently. Additionally, subsections can be moved between sections.

Deleting relations

When a relation becomes obsolete, you can delete this permanently from your workspace by clicking the “Delete” button on the relation configuration view. Currently, relations can not be deleted under the following circumstances:

• The relation is part of the Naming Rule of a Fact Sheet type
• The relation has all Fact Sheet types as target Fact Sheet types e.g., Parent/Child relation
• The relation is a constraining relation or is constrained by another relation
• The relation has the same target Fact Sheet type as the source Fact Sheet type

This is because the above relations currently can not be reconfigured. Further updates to the functionality aim to cover those exceptions.

🚧

Deleting relations

Deleting a relation will remove the relation and all attached data from both sides of the relations. This is non reversible.

Please acknowledge that deleting fields or field values from your workspace will temporarily put your workspace in a read-only mode. No Fact Sheets can be modified while these changes are processed. Usually, the workspace should be in read-only mode not longer than 15 minutes.

Add fields or field values

To add a field, the admin can select a section or subsection, when selected, you will see the option on the right panel as shown below:

To add a field value, the admin can select the field and when selected, the option on the right panel will appear as shown below:

There, the admin can add new Values, e.g., Developer, and click on the + button to add the value. You can also add a translation to the value by clicking on the value and adding the translation accordingly.

Delete fields or field values

Now, the workspace admin has access to delete DataModel fields and field values. The admin can also create and configure fields in the Fact Sheet:

📘

Special behavior for the category field

Admins can also create the category field on Fact Sheets types that do not have it by default. The category has special behaviour in the Inventory and Fact Sheet details page. End-users will be able to select it directly when creating new Fact Sheets.

Note: if the Category field is not immediately visible in the Facet Filter menu, please navigate to the Meta Model Configuration and define it as a default Facet. For more detailed instructions on how to do so see Default facet configuration

The special behaviour for this field is not available as a relation field.

To delete a field, the admin can select the field and will see the option on the right panel as shown below:

Like deleting a field, admins can also delete a field value. In the same panel, the admin can choose and proceed to delete the field value:

🚧

Attention

Fields starting with the prefix "lx" are internal fields used for integrations and other features. Deleting or changing fields, altering, adding or deleting field values of those fields might result in unwanted behaviour. We recommend to not delete or alter them, if necessary you can hide them from the Fact Sheet by moving the fields in the Unused section.

Please acknowledge that deleting fields or field values from your workspace will temporarily put your workspace in a read-only mode. No Fact Sheets can be modified while these changes are processed. Usually, the workspace should be in read-only mode not longer than 15 minutes.

During the read-only mode, the users will see this notification in their LeanIX workspace.

You will receive a confirmation email when you perform changes such as: deleting fields or field values. Other changes will be active immediately without an email confirmation.

📘

Information

You will receive this email when you do any changes in the configuration. This behavior is not specific to the deletion of fields inside the Self-Configuration, but works this way for all (mass) updates (Excel, GraphQL, Integrations). This is also necessary for auditing.

From the same panel, you can now reorder the field values by doing drag and drop to the desired positions.

In order to reduce complexity for your end users, it's often better to conceal your Fact Sheet fields and relations that are not yet in the scope of your organization's activity in LeanIX. To achieve this, you can transfer these elements to the Unused Fields and Relations section. This practice helps maintain focus on essential information and simplifies the overall experience for your end users. When your organizational scope evolves, these fields can be easily moved back to the intended sections and thus made visible again. You can move the fields by navigating to the Change position tab on the right-side panel and selecting Unused Fields from the drop-down menu.

You will find the Unused Fields and Relations section located at the bottom of the Fact Sheet configuration page. Any fields in this section remain hidden throughout the LeanIX application, allowing you to declutter your workspace without losing any data. You can move back the fields to the intended subsection from the drop-down menu on the right-side panel.

Field Value Types

These are some of the Field value Types you will find in LeanIX:

DOUBLE: A double-precision floating-point data type is used for numeric values that can include decimal points. It provides a higher precision level than a single-precision floating-point data type.

INTEGER: This is a data type used for whole numbers, which means it represents non-decimal numeric values. For example, 1, 2, 3, -5, and so on.

MULTIPLE_SELECT: Multiple-select field allows users to choose multiple options from a list. It's used when multiple choices are applicable, and users can select one or more items simultaneously.

SINGLE_SELECT: Single select field enables users to pick a single option from a list. It's suitable when only one choice is applicable or allowed.

STRING: String is a data type used for text or character-based information. It can encompass letters, numbers, symbols, and other characters, making it useful for various types of textual data.

BASE_FIELD: Base field refers to a fundamental or essential field within the database. It is a core element that often serves as a foundation for other fields and data components. Base fields can include fundamental data types like text, numbers, dates, or identifiers.

EXTERNAL_FIELD: An external field refers to a database field linked or associated with data from an external source or system. It may be used to store data retrieved or integrated from outside the current database or application. External fields are used to import and manage data originating from external systems, files, or sources.

Enabling search for new fields

Note that new fields are not searchable by default. To enable searching, create the new field and then navigate to the Options tab (gear icon). Toggle the switches Include in full-text search and Include in quick search as needed.

If you have already created a field and need to enable searching, the only way is to delete data, re-create the field and toggle the switches before clicking on the Show Changes and Apply buttons. Take care to export your data before deleting and recreating the field.

🚧

Enabling search for new fields

Exercise caution when enabling search for new fields - too many fields can slow down search performance significantly.

Field widths

When choosing the Width for the field, you can choose between XS through XXL. This T-Shirt sizing is there to help you align the fields on the Fact Sheet page. Here, you can see the T-Shirt size comparison for the Type: String and Rendered as: Text Area:

Here is the size comparison for the Type: String and Rendered as: Text:

There is no character limit associated with the size. However, fields with content longer than 32.766 characters will cause an incorrect behavior on your workspace.

Apply Changes

After configuring the Fact Sheets, you can see all the changes you just made by clicking the Show changes button. Here, you can also safely review your changes before applying them.

👍

Fact Sheet Completeness - best practice

The advanced settings are a great feature to get grip on tracking data completeness and stay focused in regard to adding new data. In regard to the completeness, make sure what use case you want to deliver and what data you need to do so. Afterward set the weight of those attributes to "0" which is not needed to deliver the use-case.

To reach 100% Fact Sheet completeness be sure that you have filled out every single field in a subsection. If there is a field without data you are not able to reach 100%.

Audit Log

You can see an overview of all historical configuration changes made on the “Audit Log” tab of the Meta Model Configuration. This overview summarises the changes, when they’ve been executed, and by who. Hoovering over the user and date entries provides additional information, such as the email and exact timing of the change.

📘

Important Note

Currently the changes are reflected in the “Changes” column instead of the “Old Value” and “New Value” format you might be used to from the Audit Log on the Fact Sheet Details page. This is due to technical complexity on our side which we are currently not able to resolve, but will explore in the future.

Additionally we will enhance the Audit Log by providing filtering functionality on different aspects such as type, user and date.

Managing Fact Sheet Types

Creating a custom Fact Sheet type

In the Meta Model Configuration space, click on the Create Fact Sheet type button at the top left, and you will see the below view.

Enter the desired Internal name for your Custom Fact Sheet type. The Internal name of the Fact Sheet Type is not the name that will be displayed in your user interface but is used for API queries, GraphQL queries, and for Import and Export.

🚧

Attention!

The internal name cannot be modified later.

In addition to the internal name, you must provide the translated labels for the new Fact Sheet type. Translating the currently logged-in user's language is mandatory, while other languages are optional. We recommend adding all translations for the languages relevant to your users immediately.

Once you submit the form, you will be taken to the Meta Model Configuration page of your new Fact Sheet type, where you can configure it further.

🚧

Note

For some users it may be neccessary to submit a ticket to the support team when creating a new Fact Sheet type depending on the customer’s authorization model configuration. Permissions for Members and Viewers might have to be adjusted to allow any reading and editing for that new Fact Sheet type. This is because LeanIX uses whitelisting instead of blacklisting for the authorization model and when the default configuration has been changed so that the edit and read rights are to be set individually, then the new Fact Sheet type doesn’t get added by default.

📘

The new custom Fact Sheet type will be visible in the Inventory when you create it. There is no functionality for hiding Fact Sheet types while they are not fully configured.

Reordering Fact Sheet types

Click the Change order button in the top right of the list of Fact Sheets types in your workspace. You can now change the position of each type using drag and drop. Click on the Save order to apply the changes. You may also click Cancel to discard the pending changes.

📘

Note

Admins have the right to create, delete and reorder Fact Sheet types.

Deleting a custom Fact Sheet type

You can delete any Fact Sheet type that is not part of the LeanIX default Fact Sheet types in the administration area of Meta Model Configuration.

To delete a custom Fact Sheet type, click the Delete button on the right end of the list item. A dialog will appear that presents you with the following data:

• The number of Fact Sheets will be deleted. To have an accessible overview of which Fact Sheets will be deleted, we provide a direct link to the inventory of the affected Fact Sheets.
• Relations that will be removed by deleting this Fact Sheet type.
• The naming rules will be affected since they are referencing deleted relations. The deletion will fail if this results in duplicate Display Names of the affected Fact Sheet type.

Tick the checkbox to the left of the Delete button to confirm your decision, which makes the delete button accessible.

Deleting a Fact Sheet type may take a while if several Fact Sheets of that type exist in your workspace. We recommend performing such deletions outside of business hours to not create a negative experience for your end-users.

❗️

Deleted Fact Sheet types and the connected data can not be recovered.

Managing Permissions

The Meta Model Configuration now includes a new tab that enables admins to manage the Create, Read, Update, and Delete (CRUD) permissions for each attribute (field, relation, etc.) on each Fact Sheet type. These permissions can be configured per user role (e.g., Viewer, Member). This feature gives organizations greater control over their workspace, allowing them to restrict access to sensitive financial data or key fields, ensuring that only responsible decision-makers can modify them.

However, the admin role itself cannot be configured to prevent any potential issues down the line, such as parts of the workspace becoming inaccessible to anyone.

Guidelines / Best practice advice

• We at LeanIX still advise you to keep a collaborative approach in mind, as we believe this is key to success with our product. Therefore we recommend not adopting extreme measures such as preventing the majority of the end users to contribute to your data quality in the workspace.
• Focus on business-critical or sensitive data to be restricted
• The more complexity you create, the tougher it will be to manage and explain. Therefore we recommend keeping the number of additional roles low.
• Permission changes are easily testable by using the "Switch User Role" functionality. Read more about this functionality here

General features

• Ease of use functionality such as
  • Search by Field of Relation name
  • Bulk edit by subsection
  • Ability to select all permissions for a single attribute
• Fields and Relations grouped as they appear in the Meta Model Configuration Fields tab
• Defining Create, Read, Update, and Delete permissions for Fact Sheet attributes
  • Create: To be able to associate a response to an attribute that is not filled out.
  • Read: To be able to see an attribute.
  • Update: To be able to edit information that is already existing for an attribute.
  • Delete: To be able to remove information that has been entered and saved for a particular Fact Sheet within a particular attribute.
• Configuring Advanced Permissions such as SubscriptionCheck

General Permissions

The General Permissions section includes items that affect the entire Fact Sheet type. These actions are not based on the CRUD format but use a toggle pattern: Yes means the user has the ability to perform the action, and No means the user does not have the ability. Here's a brief overview of the different options.

Global Permissions

The Global Permissions section contains attributes that are not fields on the Fact Sheet level, but still are part of the specific Fact Sheet. An example would be functionality such as Subscriptions on the Fact Sheet details page.

Field Permissions

The Field Permissions section contains all the fields that are present on the Fact Sheet type. They are displayed in the structure of sections and subsections, as they appear on the Fact Sheet details page and the Meta Model Configuration.

Relation Permissions

Relation permissions are grouped in the same order as they appear on the Fact Sheet details page. This helps admins navigate to the right relations quickly.

Relation fields are grouped below each relation and have a reduced set of actions available to them, the Create and Update actions do not have any function and are therefore disabled for selection.

📘

Note

• Global Relations, such as our out of the box Parent & children relations are not currently configurable nor displayed in the Meta Model Configuration.
• Bulk-editing all fields in a relation subsection is not supported.

Advanced Permissions

Instead of creating new roles for specific scenarios, advanced permissions based on subscription type (e.g. Accountable, Responsible) or tags can be leveraged. The advanced permissions section allows the admins to add the following types of permissions:

Subscription-based Permissions

A subscription-based permission allows admins to define Create, Read, Update, and/or Delete access based on that user's subscription type for that particular Fact Sheet type. Updating the Quality Seal is an example of this kind of permission that’s defined per default. This allows viewers or members, who normally don’t have permission to update the Quality Seal, to receive additional permissions if they have a Responsible or Accountable subscription. This enables the scenario to grant additional permissions to the right stakeholders, for a specific Fact Sheet type.

Tag based Permissions

A tag-based permission allows the admins to define read, create, delete, and or update access for an attribute when that tag is added to a particular Fact Sheet.

For transparency, any deviations Advanced Permissions create from the non-advanced permissions are highlighted with an indicator on each attribute’s configuration. Clicking on this indicator will execute a search for the related attribute, providing you with a quick side-by-side comparison of both.

Advanced permissions are used as an extension on top of the non-advanced permissions, granting additional permissions in a specific scenario. Therefore, an advanced permission for an attribute will always overwrite the permissions of the attribute with non-advanced permissions. For example, if the Name attribute has Create and Update permissions set as True, and an advanced permission for the Name attribute is added where Create is set as True, the Create permission, in this case, will be set to False automatically in order to avoid conflicting permissions. In such cases, the admin will be notified with an overview of changes that overwrite the non-advanced permissions, with an option to revert one or more advanced permission changes.

📘

• Subscription Self permissions are referring to whether or not end users can assign themselves subscriptions. This permission can only be added to the Subscriptions attribute.
• Advanced Permissions on relation fields are not supported.