Attribute Changes In A Case

Overview

The Attribute Changes in a Case enrichment is a powerful analytical tool that detects and quantifies value changes in event attributes throughout the lifecycle of a case. This enrichment automatically examines every event attribute in your dataset and creates new case-level metrics that reveal patterns of change, stability, and variation within each process instance. By transforming event-level variations into case-level insights, this enrichment enables you to identify process inconsistencies, track state transitions, and measure process stability at scale.

This enrichment is particularly valuable for understanding process dynamics and variability. It answers critical questions about how attribute values evolve during case execution - whether status fields change frequently, if resource assignments remain consistent, or how many distinct values an attribute takes within a single case. The enrichment creates up to three different types of metrics for each event attribute, giving you flexibility in how you analyze and visualize attribute changes across your process.

Common Uses

• Status transition analysis - Track how many times order status, approval status, or case status changes throughout the process lifecycle
• Resource consistency monitoring - Identify cases where ownership or responsibility changes hands multiple times, indicating potential handover issues
• Data quality validation - Detect unexpected variations in attributes that should remain constant, revealing data entry errors or system inconsistencies
• Process complexity measurement - Quantify the number of distinct values or states a case passes through to measure process complexity
• Change frequency analysis - Count the total number of value changes to identify highly volatile cases requiring investigation
• Conformance checking - Verify that certain attributes maintain expected values or change patterns according to business rules
• Performance categorization - Group cases by their change patterns to understand which types of cases follow simpler versus more complex paths

Settings

Ignore Null: Determines whether null (empty) values should be excluded when analyzing attribute changes. When enabled, the enrichment will skip over events where the attribute value is null, focusing only on actual value changes. This is useful when null values represent missing data rather than meaningful state changes. Default value is true (enabled). Enable this when nulls represent data gaps; disable when null is a meaningful state in your process.

Create Change Count Attribute: Controls whether to create attributes that count the total number of value changes for each event attribute. When enabled, creates attributes with the suffix "-Changes" that contain the count of how many times the value changed from one event to the next. This provides a sequential change count metric. Default value is true (enabled). Use this to measure volatility and identify cases with frequent state transitions.

Create Group Count Attribute: Determines whether to create attributes that count the number of distinct values (groups) each event attribute takes within a case. When enabled, creates attributes with the suffix "-Groups" containing the count of unique values. This measures diversity rather than change frequency. Default value is true (enabled). Enable this to understand value diversity and process complexity.

Create Bool Change Attribute: Controls whether to create boolean attributes indicating if any change occurred for each event attribute. When enabled, creates attributes with the suffix "-Change" that contain true/false values - true if the attribute had any distinct values, false otherwise. Default value is true (enabled). Use this for simple binary classification of cases with or without changes.

Examples

Example 1: Order Status Monitoring in Procurement

Scenario: A procurement team needs to identify purchase orders with excessive status changes, which often indicate process complications or delays requiring manual intervention.

Settings:

• Ignore Null: true
• Create Change Count Attribute: true
• Create Group Count Attribute: true
• Create Bool Change Attribute: false

Output: For an event attribute "Order_Status" that transitions through values: "Created" → "Approved" → "In Review" → "Approved" → "Processed", the enrichment creates:

• Order_Status-Changes: 4 (counts each transition)
• Order_Status-Groups: 4 (counts distinct values: Created, Approved, In Review, Processed)

Cases with Order_Status-Changes > 5 are flagged for review as they indicate repeated back-and-forth status changes.

Insights: Orders with high change counts correlate with longer cycle times and higher costs. The procurement team implements automated alerts for orders exceeding 3 status changes to proactively manage exceptions.

Example 2: Patient Care Team Transitions in Healthcare

Scenario: A hospital wants to analyze care continuity by tracking how often patients are transferred between different medical teams or departments during their stay.

Settings:

• Ignore Null: true
• Create Change Count Attribute: true
• Create Group Count Attribute: true
• Create Bool Change Attribute: true

Output: For an event attribute "Assigned_Team" with values: "ER" → "ER" → "ICU" → "Surgery" → "ICU" → "Recovery", the enrichment creates:

• Assigned_Team-Changes: 4 (ER to ICU, ICU to Surgery, Surgery to ICU, ICU to Recovery)
• Assigned_Team-Groups: 4 (ER, ICU, Surgery, Recovery)
• Assigned_Team-Change: true (changes occurred)

Insights: Patients with more than 3 team transitions show 40% longer average length of stay. The hospital implements care coordination protocols for high-transition patients to improve outcomes and efficiency.

Example 3: Manufacturing Quality Control Tracking

Scenario: A manufacturing plant needs to monitor quality inspection results throughout the production process to identify products requiring multiple quality interventions.

Settings:

• Ignore Null: false
• Create Change Count Attribute: true
• Create Group Count Attribute: true
• Create Bool Change Attribute: false

Output: For an event attribute "Quality_Status" with values: null → "Pass" → "Fail" → "Rework" → "Pass", the enrichment creates:

• Quality_Status-Changes: 4 (including the initial null to Pass transition)
• Quality_Status-Groups: 5 (null, Pass, Fail, Rework, and Pass counted as distinct)

Products with Quality_Status-Groups > 2 are analyzed for root cause analysis of quality issues.

Insights: Products experiencing quality status changes correlate with specific production lines and shifts, leading to targeted training and equipment maintenance programs.

Example 4: Financial Transaction Approval Workflow

Scenario: A bank wants to analyze the complexity of their loan approval process by tracking how many different approval levels and decision states each application passes through.

Settings:

• Ignore Null: true
• Create Change Count Attribute: false
• Create Group Count Attribute: true
• Create Bool Change Attribute: true

Output: For an event attribute "Approval_Level" with values: "Initial_Review" → "Credit_Check" → "Manager_Review" → "Credit_Check" → "Final_Approval", the enrichment creates:

• Approval_Level-Groups: 4 (Initial_Review, Credit_Check, Manager_Review, Final_Approval)
• Approval_Level-Change: true

Loan applications with Approval_Level-Groups > 5 indicate complex cases requiring process optimization.

Insights: Applications with fewer approval level groups have 60% faster processing times. The bank streamlines the process for standard applications while maintaining thorough review for complex cases.

Example 5: IT Incident Resolution Tracking

Scenario: An IT service desk needs to track how often incident priorities and assignees change to identify tickets that bounce between teams without resolution.

Settings:

• Ignore Null: true
• Create Change Count Attribute: true
• Create Group Count Attribute: true
• Create Bool Change Attribute: true

Output: For event attributes "Priority" and "Assigned_Group":

• Priority-Changes: Number of priority escalations or de-escalations
• Priority-Groups: Count of distinct priority levels used
• Assigned_Group-Changes: Number of times the ticket was reassigned
• Assigned_Group-Groups: Number of different teams that handled the ticket
• Assigned_Group-Change: true/false indicating if any reassignment occurred

Tickets with both Priority-Changes > 2 and Assigned_Group-Changes > 3 are flagged as "hot potato" tickets requiring management attention.

Insights: Incidents with multiple reassignments show 3x longer resolution times. The service desk implements a "sticky assignment" policy where the first responding team must coordinate resolution even if expertise from other teams is needed.

Output

The Attribute Changes in a Case enrichment creates new case-level attributes for each non-system event attribute in your dataset. The enrichment automatically processes all event attributes except system columns (Activity, Timestamp, Start Time) and hidden or calculated columns.

Generated Attributes:

• [AttributeName]-Changes (Integer): Contains the count of value transitions for the attribute. A change is counted each time the value differs from the previous event. Values range from 0 (no changes) to n-1 where n is the number of events in the case.

• [AttributeName]-Groups (Integer): Contains the count of distinct values the attribute takes within the case. This measures value diversity regardless of change frequency. A value of 1 indicates the attribute remained constant throughout the case.

• [AttributeName]-Change (Boolean): Contains true if the attribute had any distinct values within the case, false if it remained constant or had no values. This provides a simple binary indicator of change presence.

Data Types and Formats:

• Change count attributes: Integer values displayed with number formatting
• Group count attributes: Integer values displayed with number formatting
• Boolean change attributes: Boolean values displayed as Yes/No

Integration with Other Features:

• Use these attributes in filters to identify cases with specific change patterns
• Combine with calculators to create change ratios or percentages
• Apply in dashboards to visualize process stability metrics
• Use in conformance checking to verify expected change patterns
• Leverage in machine learning models as process complexity features

Naming Conventions: The enrichment preserves the original attribute name and appends clear suffixes (-Changes, -Groups, -Change) making it easy to identify the source attribute and metric type. These attributes appear in the case attribute list and can be used immediately in all mindzieStudio analysis features.

---

This documentation is part of the mindzie Studio process mining platform.