change attribute display name

Overview

The Change Attribute Display Name enrichment modifies how an attribute appears in the user interface without altering its underlying technical name or data. This powerful cleanup operator provides a critical layer of abstraction between technical attribute names and business-friendly labels, enabling you to present data in terms that are meaningful to business users while maintaining the integrity of the underlying data structure. The enrichment operates at the metadata level, updating only the display property of the selected attribute column.

This enrichment is essential for transforming technical or system-generated attribute names into clear, business-oriented terminology that stakeholders can immediately understand. For instance, you might have attributes with technical names like "PO_AMT_USD" or "CUST_ID_001" that need to be presented as "Purchase Order Amount" or "Customer ID" for better readability. The Change Attribute Display Name enrichment makes this transformation seamless, improving the usability of your process mining analysis without requiring any changes to the underlying data model or breaking existing filters, calculators, or other enrichments that reference the original attribute name.

Common Uses

Transform technical database column names into business-friendly labels for reports and dashboards
Standardize attribute naming conventions across different data sources in merged datasets
Implement internationalization by changing display names to different languages for global teams
Create context-specific labels when the same attribute means different things in different processes
Improve readability of automatically generated attributes from other enrichments or calculations
Align attribute names with corporate terminology standards and business glossaries
Make cryptic system-generated field names understandable for non-technical users

Settings

Attribute Name: Select the attribute whose display name you want to change. The dropdown list shows all available case attributes in your dataset, excluding calculated fields and hidden attributes. This ensures you're only modifying attributes that are actually stored in the data. The selection determines which attribute's display property will be updated.

New Attribute Display Name: Enter the new display name for the selected attribute. This is the name that will appear in all user interfaces, reports, and visualizations throughout mindzieStudio. The new name should be clear, descriptive, and follow your organization's naming conventions. There are no restrictions on the characters you can use, allowing for spaces, special characters, and even unicode characters if needed for internationalization. The display name can be as long as necessary to properly describe the attribute's meaning.

Examples

Example 1: Purchase Order System Integration

Scenario: After importing data from an ERP system, you have attributes with technical database names like "PO_HDR_CRDT", "VNDR_CODE", and "APPR_STATUS" that need to be made understandable for business analysts reviewing the procurement process.

Settings:

Attribute Name: PO_HDR_CRDT
New Attribute Display Name: Purchase Order Creation Date

Output: The attribute "PO_HDR_CRDT" will now display as "Purchase Order Creation Date" in all views, filters, and reports. The underlying data and technical name remain unchanged, ensuring compatibility with existing configurations.

Insights: Business users can now easily identify and work with the creation date field without needing to understand the technical abbreviation, reducing training time and improving self-service analytics adoption.

Example 2: Multi-Language Support for Global Teams

Scenario: A multinational company needs to present the same process data to teams in different countries, requiring attribute names in local languages while maintaining a single underlying dataset.

Settings:

Attribute Name: Customer_Region
New Attribute Display Name: Region Cliente (Spanish)

Output: The attribute appears as "Region Cliente" in the Spanish version of the analysis, making it immediately understandable for Spanish-speaking team members. The technical name "Customer_Region" remains unchanged for system operations.

Insights: Teams across different regions can work with the same dataset using terminology familiar to them, improving collaboration and reducing misinterpretation of data fields.

Example 3: Healthcare Claims Processing

Scenario: In a healthcare claims process, medical coding attributes like "ICD10_PRIM", "DRG_CODE", and "CPT_MOD" need clearer names for claims analysts who aren't familiar with medical coding abbreviations.

Settings:

Attribute Name: ICD10_PRIM
New Attribute Display Name: Primary Diagnosis Code (ICD-10)

Output: The cryptic "ICD10_PRIM" field now displays as "Primary Diagnosis Code (ICD-10)", providing both clarity about the field's purpose and context about the coding system used.

Insights: Claims analysts can quickly identify diagnostic information without memorizing technical abbreviations, leading to faster claim reviews and fewer errors in data interpretation.

Example 4: Financial Reconciliation Process

Scenario: After merging data from multiple financial systems, you have similar attributes with different naming conventions like "AMT_USD" from one system and "TransactionAmount" from another that need consistent presentation.

Settings:

Attribute Name: AMT_USD
New Attribute Display Name: Transaction Amount (USD)

Output: Both the "AMT_USD" and after changing "TransactionAmount" display names, all monetary fields follow a consistent naming pattern with currency clearly indicated, improving data interpretation accuracy.

Insights: Standardized display names across merged datasets reduce confusion and ensure accurate financial analysis, especially when dealing with multi-currency transactions.

Example 5: Manufacturing Quality Control

Scenario: In a quality control process, sensor-generated attributes like "TEMP_S1_AVG", "PRES_S2_MAX", and "VISC_S3_STD" need human-readable names for quality engineers reviewing production data.

Settings:

Attribute Name: TEMP_S1_AVG
New Attribute Display Name: Average Temperature - Sensor 1

Output: The technical sensor reading code "TEMP_S1_AVG" now clearly indicates it represents average temperature readings from sensor 1, making it immediately understandable in quality reports.

Insights: Quality engineers can quickly identify which sensor readings correspond to which production parameters, enabling faster root cause analysis of quality issues without constantly referencing sensor documentation.

Output

The Change Attribute Display Name enrichment modifies the display metadata of the selected attribute without creating new attributes or altering the underlying data. The original attribute's technical name remains unchanged and continues to function in all existing configurations, filters, and calculations. The new display name appears immediately in all user interface elements including:

Attribute selection dropdowns in filters and calculators
Column headers in data views and case explorers
Axis labels in charts and visualizations
Field names in exported reports
Attribute lists in enrichment configurations

The change is persistent and will remain in effect for all future analysis sessions. However, any references to the attribute in formulas, scripts, or API calls must continue to use the original technical name. This separation between display and technical names ensures backward compatibility while improving usability.

Overview

Common Uses

Settings

Examples

Example 1: Purchase Order System Integration

Example 2: Multi-Language Support for Global Teams

Example 3: Healthcare Claims Processing

Example 4: Financial Reconciliation Process

Example 5: Manufacturing Quality Control

Output

See Also