Introducing the "Key description (fx)" feature for customization of references

Wiki
1

Standardizing Display Formats for References Using Composability (Platform 3.9+)

In real-world implementations, customers often have different preferences for how entities—such as customers, suppliers, products, or warehouses—should be displayed and searched within business applications.

This primarily affects search links and dropdowns used to define foreign key relations.

The Challenge

Until now, developers had to define the display format for each reference individually within every component. For instance, customer references were typically shown by name only.

However, requirements from end users have become more diverse. Some want to see customers displayed as:

  • Debtor number – Name
  • Name – Customer number
  • or simply Name

Similar variations are being requested for other entities like warehouses, departments, and products.

The New Approach (Platform 3.9+)

Starting with Platform version 3.9, a more composable method is available that simplifies and standardizes how references are displayed—while still allowing flexibility for end-user needs.

How it works:

  1. Dedicated Display Components
    Create small, focused components that define how a contact (or other entity) should be displayed. For example:

    • M11208: Displays Debtor number – Name (includes caching for better search performance)

      image
      image1071×462 24.4 KB

    • M11209: Displays Name only
      These components act as substitutes based on display preferences.

      image
      image741×231 8.55 KB

  2. Standard Output Feature
    Each component outputs the same feature:
    N_Contact.Key description (fx)

    image
    image407×222 11.1 KB

  3. Decoupled Consumption
    Other components use N_Contact.Key description (fx) in their search links, so developers no longer need to define presentation logic in each place.

  4. Composable Configuration
    Application composers can choose between M11208, M11209, or any other component that provides the N_Contact.Key description (fx) feature. The application’s composition determines the final display format.

Updating Existing Components

Existing components can be updated without regression. Here’s the process:

  • Replace references to N_Contact.Name with N_Contact.Key description (fx)
  • On first update, application composers will be prompted to select the display component
  • As more components are updated, consistency across the application will naturally increase

Available implementations

As of July 2025, this way of working is available on the following concepts:

N_Contact, implemented by M11208 and M11209
N_Warehouse, implemented by M11155 and M11156
N_Sale, implemented by M11330and M11329
N_Purchase, implemented by M11336 and M11337

By leveraging composability, you can now standardize display formats across your application while preserving flexibility and control for end users.

2

Do I understand this correctly: we can make a component for N_Service, with key description (fx) ‘Schadeclaim’ for example. We produce this, and this will be seen in Kendo instead of Service request?