Overview
The Event Order Algorithm enrichment is a system-level configuration enrichment that controls how mindzieStudio orders events within each case when timestamps lack sufficient granularity or when multiple events share the same timestamp. This enrichment is critical for ensuring accurate process flow analysis and visualization, particularly when dealing with data sources that record only dates without specific times, or when events are inserted into the log after initial data loading.
In process mining, the sequence of activities is fundamental to understanding process behavior, calculating durations, identifying bottlenecks, and detecting conformance issues. However, many source systems record only the date of an event without the precise time, or multiple events may be logged with identical timestamps. The Event Order Algorithm enrichment provides intelligent sorting strategies to establish a consistent, meaningful order for these events, ensuring that your process analysis reflects the true sequence of operations.
This enrichment works at the event log level and affects how all subsequent analysis, visualizations, and calculations interpret event sequences. It is typically configured once at the beginning of your enrichment pipeline, though you may need to adjust it if you discover that your data has specific ordering requirements or if you add new data sources with different timestamp characteristics.
Common Uses
- Establish deterministic event ordering when source system timestamps lack time-of-day information (dates only)
- Handle data imports where events are inserted into the log with current timestamps rather than actual event times
- Ensure consistent event sequencing across different data extractions and log rebuilds
- Improve process flow visualization accuracy when dealing with low-resolution timestamp data
- Support conformance checking by providing predictable event sequences for comparison against expected models
- Optimize performance by eliminating unnecessary sorting operations when event order is already correct
- Handle legacy data migrations where historical events may be loaded with insert timestamps
Settings
Order Event Algorithm: Specifies the algorithm used to order events within each case. This setting determines how mindzieStudio resolves the sequence of events when timestamps alone are insufficient to establish a definitive order. The available options are:
Insert Date Events Before (Default): This is the recommended algorithm for most scenarios. It sorts events within each case by timestamp, and when multiple events share the same timestamp (particularly when the timestamp contains only a date without time), it uses the Expected Order attribute to determine sequence. This algorithm assumes that events with date-only timestamps were inserted into the log after the fact and should be ordered using additional metadata. The Expected Order attribute is typically set by the Expected Order enrichment, which allows you to define the logical sequence of activities in your process. This option provides intelligent handling of mixed-precision timestamps while maintaining good performance.
Insert Date Events Before (Old): This is a legacy version of the Insert Date Events Before algorithm maintained for backward compatibility with older event logs. It implements the same sorting logic but uses an older code path that may have different performance characteristics on very large datasets. Use this option only if you need to maintain consistency with historical analysis results or if you encounter specific compatibility issues with the newer algorithm. For new analyses, the standard Insert Date Events Before option is preferred.
No Sorting: This option disables automatic event sorting entirely, preserving the original order in which events appear in the source data. Use this setting when your source data already has events in the correct chronological order and you want to maximize performance by avoiding unnecessary sorting operations. This is appropriate for data sources that provide high-precision timestamps (including milliseconds) and where you are confident that the insertion order matches the chronological order. However, be cautious with this option, as it may lead to incorrect process flows if your source data does not guarantee proper ordering. If you later add calculated events or merge data from multiple sources, you may need to switch to an active sorting algorithm.
Examples
Example 1: Purchase Order Processing with Date-Only Timestamps
Scenario: A procurement system tracks purchase orders through approval, but the legacy ERP system only records the approval date without specific times. Multiple approval steps (department manager, finance controller, executive approval) may occur on the same day, but the timestamp shows only "2024-03-15" for all three approvals. Without proper ordering, process mining would show random sequences, making it impossible to identify the true approval path or calculate accurate handover times.
Settings:
- Order Event Algorithm: Insert Date Events Before
Additional Configuration: Before applying this enrichment, you would first use the Expected Order enrichment to define that:
- Department Manager Approval always comes first
- Finance Controller Approval comes second
- Executive Approval comes last
Output: With Insert Date Events Before selected, events sharing the timestamp "2024-03-15 00:00:00" are now correctly ordered:
| Case ID | Activity | Original Timestamp | Sorted Position | Expected Order |
|---|---|---|---|---|
| PO-1234 | Department Manager Approval | 2024-03-15 | 1 | 10 |
| PO-1234 | Finance Controller Approval | 2024-03-15 | 2 | 20 |
| PO-1234 | Executive Approval | 2024-03-15 | 3 | 30 |
The process flow now correctly shows the approval hierarchy, duration calculations between steps become meaningful, and conformance checking can validate that the expected approval sequence was followed.
Insights: This configuration ensures that even with date-only timestamps, your process mining analysis accurately represents the mandatory approval hierarchy. Without this enrichment, the three approvals might appear in random order across different cases, obscuring patterns and making it impossible to detect cases where approvals occurred out of sequence.
Example 2: High-Performance Analysis with Precise Timestamps
Scenario: A manufacturing execution system (MES) logs every production step with millisecond-precision timestamps. Each workstation records start and completion times for operations like "Material Loaded," "Welding Complete," "Quality Inspection," and "Packing Finished" with timestamps like "2024-03-15 14:32:18.437." The data volume is substantial (millions of events), and you want to optimize enrichment performance since the timestamps already provide unambiguous ordering.
Settings:
- Order Event Algorithm: No Sorting
Output: Events are processed in their original insertion order without additional sorting:
| Case ID | Activity | Timestamp | Original Order Preserved |
|---|---|---|---|
| WO-5678 | Material Loaded | 2024-03-15 14:32:18.437 | Position 1 |
| WO-5678 | Welding Complete | 2024-03-15 14:35:42.891 | Position 2 |
| WO-5678 | Quality Inspection | 2024-03-15 14:38:15.234 | Position 3 |
| WO-5678 | Packing Finished | 2024-03-15 14:41:03.567 | Position 4 |
Enrichment processing completes 15-20% faster compared to using active sorting algorithms, particularly noticeable when regenerating the case view after applying multiple enrichments.
Insights: When your source data provides high-quality, high-precision timestamps, disabling sorting can significantly improve performance on large datasets without sacrificing accuracy. This is particularly valuable in real-time or near-real-time process mining scenarios where enrichment speed matters. However, monitor your process flows carefully when first implementing this setting to ensure your source data truly maintains correct ordering.
Example 3: Historical Data Migration with Mixed Timestamps
Scenario: A financial services company is migrating 10 years of loan application data from a legacy system to a new process mining platform. Historical events (2015-2020) have only date stamps, while recent events (2021-present) include precise timestamps. Additionally, some historical events were bulk-loaded into the current system and carry insert timestamps from the migration date rather than the actual event dates. The Expected Order enrichment has been configured to define the standard loan origination sequence: Application Received, Credit Check, Income Verification, Underwriting Review, Approval Decision.
Settings:
- Order Event Algorithm: Insert Date Events Before
Output: For a historical case from 2017:
| Case ID | Activity | Stored Timestamp | Event Date | Sorted Position | Expected Order |
|---|---|---|---|---|---|
| LN-9012 | Application Received | 2017-06-12 | 2017-06-12 | 1 | 10 |
| LN-9012 | Credit Check | 2017-06-12 | 2017-06-12 | 2 | 20 |
| LN-9012 | Income Verification | 2017-06-13 | 2017-06-13 | 3 | 30 |
| LN-9012 | Underwriting Review | 2017-06-13 | 2017-06-13 | 4 | 40 |
| LN-9012 | Approval Decision | 2017-06-14 10:30:00 | 2017-06-14 | 5 | 50 |
For a recent case from 2024:
| Case ID | Activity | Stored Timestamp | Sorted Position |
|---|---|---|---|
| LN-9876 | Application Received | 2024-03-15 09:15:23 | 1 |
| LN-9876 | Credit Check | 2024-03-15 09:47:11 | 2 |
| LN-9876 | Income Verification | 2024-03-15 14:22:35 | 3 |
| LN-9876 | Underwriting Review | 2024-03-16 08:30:12 | 4 |
| LN-9876 | Approval Decision | 2024-03-16 16:45:08 | 5 |
Insights: The Insert Date Events Before algorithm seamlessly handles mixed data quality scenarios, using Expected Order to sequence same-day events in historical data while relying on precise timestamps for recent data. This allows you to perform consistent process analysis across your entire dataset regardless of timestamp precision, enabling accurate trend analysis and comparison between historical and current process performance. The algorithm automatically detects when timestamps lack time-of-day information and applies the appropriate ordering logic.
Example 4: Multi-System Data Integration
Scenario: A healthcare provider combines patient journey data from three systems: an appointment scheduling system (timestamps with seconds precision), an electronic medical records (EMR) system (date-only timestamps for many historical entries), and a billing system (timestamps with minute precision). Events like "Appointment Scheduled," "Patient Arrived," "Vitals Recorded," "Doctor Consultation," "Lab Order," "Lab Results," "Prescription Issued," and "Billing Complete" come from different sources with varying timestamp precision. The Expected Order enrichment defines the typical patient visit sequence.
Settings:
- Order Event Algorithm: Insert Date Events Before
Output: For a patient visit on March 15, 2024:
| Case ID | Activity | Source System | Original Timestamp | Sorted Position | Expected Order Applied |
|---|---|---|---|---|---|
| PT-4455 | Appointment Scheduled | Scheduling | 2024-03-10 14:30:00 | 1 | No (precise time) |
| PT-4455 | Patient Arrived | Scheduling | 2024-03-15 09:00:00 | 2 | No (precise time) |
| PT-4455 | Vitals Recorded | EMR | 2024-03-15 | 3 | Yes (date only, order 30) |
| PT-4455 | Doctor Consultation | EMR | 2024-03-15 | 4 | Yes (date only, order 40) |
| PT-4455 | Lab Order | EMR | 2024-03-15 | 5 | Yes (date only, order 50) |
| PT-4455 | Lab Results | EMR | 2024-03-15 | 6 | Yes (date only, order 60) |
| PT-4455 | Prescription Issued | EMR | 2024-03-15 | 7 | Yes (date only, order 70) |
| PT-4455 | Billing Complete | Billing | 2024-03-15 17:00 | 8 | No (hour/minute) |
Insights: The Insert Date Events Before algorithm intelligently adapts to varying timestamp precision across integrated data sources. It preserves the chronological order provided by precise timestamps while using Expected Order to sequence events from systems with lower timestamp resolution. This enables comprehensive end-to-end process mining across disparate systems without requiring expensive data quality improvements or timestamp enrichment at the source system level. The resulting process flows accurately represent patient journeys, enabling analysis of handoffs, waiting times, and resource utilization.
Example 5: Backward Compatibility for Historical Analysis
Scenario: A process mining team has been analyzing order fulfillment processes for three years using an older version of mindzieStudio. They have published multiple reports, dashboards, and KPIs based on this analysis. After upgrading to a newer version of the platform, they notice slight differences in some process metrics, particularly around same-day activities. Investigation reveals that the event ordering algorithm has been updated with performance improvements. To maintain consistency with historical reports and ensure year-over-year comparisons remain valid, they need to use the legacy ordering algorithm.
Settings:
- Order Event Algorithm: Insert Date Events Before (Old)
Output: Process metrics and flow diagrams match exactly with previously published analysis:
Current Analysis (using Old algorithm):
- Average order processing time: 4.2 days
- On-time delivery rate: 87.3%
- Process variant distribution matches historical baseline
- Conformance rate: 91.2%
Comparison with New Algorithm:
- Average order processing time: 4.2 days (no change, precise timestamps)
- On-time delivery rate: 87.3% (no change)
- Process variant distribution: 2 new rare variants detected (0.1% of cases)
- Conformance rate: 91.0% (slight decrease due to refined ordering)
Insights: The Old algorithm option provides continuity for long-term process mining initiatives where consistency with historical analysis is critical. While the newer algorithm offers better performance and potentially more accurate ordering in edge cases, the old algorithm ensures that established KPIs, benchmarks, and trend analyses remain comparable across the upgrade transition. Teams can use this option during a transition period, validate differences between algorithms on a subset of data, and then switch to the new algorithm for future analysis once baseline comparisons are established. This approach maintains stakeholder confidence in the analysis while enabling platform modernization.
Output
The Event Order Algorithm enrichment does not create new attributes or modify existing data values. Instead, it configures a system-level setting that controls how mindzieStudio internally orders events when building the case view for analysis and visualization. The impact of this enrichment is visible in:
Process Flow Visualization: Process maps, variant analysis, and directly-follows graphs will reflect the event sequences determined by the selected algorithm. Cases with same-timestamp events will show consistent, logical flow patterns rather than random ordering.
Duration Calculations: Enrichments that calculate time between activities (such as "Duration Between Two Activities" or "Duration Between Activity and Case Start") will produce meaningful results because events are in the correct sequence. Without proper ordering, duration calculations between same-timestamp events would be zero or could show negative durations if events appeared in reverse order.
Conformance Checking: Conformance enrichments that validate activity sequences against expected process models will correctly identify deviations. Proper event ordering ensures that conformance violations reflect actual process problems rather than data quality issues.
Performance Analysis: Performance categorization enrichments that classify cases based on duration thresholds or time-based criteria will operate on correctly sequenced events, ensuring accurate performance assessments.
Downstream Enrichments: All subsequent enrichments in your enrichment pipeline that depend on event order (activity position, predecessor/successor relationships, case stage calculations) will operate correctly based on the ordering established by this enrichment.
The enrichment operates during the case view generation phase, which occurs after the event log is loaded and whenever enrichments are applied. The performance impact varies by algorithm:
- No Sorting provides the best performance by skipping the ordering step entirely
- Insert Date Events Before offers a balance of accuracy and performance, optimized for modern datasets
- Insert Date Events Before (Old) maintains backward compatibility but may be slower on very large datasets
When you apply this enrichment, mindzieStudio regenerates the case view using the selected algorithm. The internal event sequence is updated, but the original timestamp values in your data remain unchanged. This means you can switch between algorithms without modifying your source data, allowing you to experiment with different ordering strategies to find the approach that best represents your process reality.
See Also
- Expected Order - Defines the logical sequence of activities in your process, which is used by the Insert Date Events Before algorithms to order same-timestamp events
- Freeze Log Time - Sets a fixed reference point for time-based calculations, useful when analyzing historical data or creating reproducible analyses
- Shift Activity Time - Adjusts timestamps by a specified offset, helpful when correcting timezone issues or aligning data from different sources
This documentation is part of the mindzieStudio process mining platform.