Overview
The Cases with Identical Event Timestamps filter identifies cases where multiple activities occurred at exactly the same timestamp, down to the millisecond. This filter is valuable for detecting data quality issues, identifying simultaneous process execution, or finding cases where events were logged in bulk with identical timestamps. You can choose to include cases with same-time activities or exclude them, depending on whether you're investigating timestamp anomalies or focusing on properly sequenced cases.
Common Uses
- Detect data quality issues where multiple events have identical timestamps
- Identify cases with suspicious timestamp patterns that may indicate data loading errors
- Find cases where parallel activities were executed simultaneously
- Exclude cases with timestamp anomalies from process analysis
- Investigate batch processing or bulk data loading scenarios
- Clean datasets by focusing only on cases with properly sequenced timestamps
Settings
Include or Exclude Cases: Choose whether to include cases that have same-time activities or exclude them.
- Include cases with same-time activities: Returns only cases where at least two events occurred at exactly the same timestamp
- Exclude cases with same-time activities: Returns only cases where all events have different timestamps (properly sequenced)
Examples
Example 1: Finding Data Quality Issues
Scenario: Your process mining dataset was imported from a legacy system. You suspect that some cases have data quality issues where multiple events were logged with identical timestamps, which shouldn't happen in your sequential approval workflow.
Settings:
- Include cases with same-time activities
Result:
The filter returns all cases where two or more events share exactly the same timestamp. For example, if Case #12345 has "Submit Request" and "Manager Approval" both timestamped at 2024-10-15 14:32:18.450, this case would be included in the results. If you had 5,000 cases with 120 showing timestamp anomalies, those 120 cases are returned.
Insights: These cases likely represent data quality issues that need investigation. Events in a sequential approval workflow shouldn't occur at the exact same millisecond. This could indicate bulk data loading, system clock issues, or improper event logging. Review these cases with your data team to determine the root cause.
Example 2: Analyzing Clean Sequential Cases
Scenario: You want to perform accurate process variant analysis and need to exclude cases with timestamp anomalies. Your goal is to analyze only cases where events occurred at distinct times, ensuring proper sequential ordering.
Settings:
- Exclude cases with same-time activities
Result:
The filter returns only cases where all events have unique timestamps. If you had 5,000 cases with 120 showing timestamp collisions, the filter returns the remaining 4,880 cases where all events are properly sequenced in time. Each case in the result has events with distinct timestamps.
Insights: By excluding cases with identical timestamps, you ensure your variant analysis is based on properly sequenced data. This provides more accurate cycle times, bottleneck identification, and variant frequencies since all events have clear temporal ordering.
Example 3: Investigating Bulk Processing
Scenario: Your warehouse management system processed a large batch of shipments overnight. You want to identify which cases were part of the bulk processing where multiple activities (Pick, Pack, Label) might have been logged simultaneously.
Settings:
- Include cases with same-time activities
Result:
The filter identifies cases where multiple warehouse activities share the same timestamp. For example, Case #WH-7890 might show "Pick Items," "Pack Box," and "Generate Label" all timestamped at 2024-10-15 03:15:22.000, indicating bulk processing. If 200 shipments were processed in the batch, those 200 cases would be returned.
Insights: These cases represent bulk processing events where multiple steps were completed and logged simultaneously rather than individually. This helps you separate bulk-processed cases from normal sequential cases, allowing different analysis approaches for each processing mode.
Example 4: Validating Real-Time Transaction Logging
Scenario: Your financial transaction system should log each step (Transaction Initiated, Validation, Authorization, Completion) with precise timestamps. You want to verify that your real-time logging is working correctly by finding any cases with timestamp collisions.
Settings:
- Include cases with same-time activities
Result:
The filter returns cases where two or more transaction steps have identical timestamps. Ideally, this should return zero cases in a properly functioning real-time system. If you find 15 cases out of 50,000 with timestamp collisions, these warrant investigation.
Insights: Cases with identical timestamps in a real-time transaction system indicate potential issues with event logging or system clock resolution. A small number might be acceptable, but a large number suggests systematic problems with your timestamp capture mechanism that should be addressed.
Output
This filter operates at the case level and filters entire cases based on timestamp analysis:
- Include mode: Returns only cases containing at least two events with identical timestamps
- Exclude mode: Returns only cases where all events have unique timestamps
- Case and event attributes are preserved
- Event sequences and all other properties remain unchanged
- The filter performs exact timestamp comparison (including milliseconds)
Use this filter to identify data quality issues or to ensure your analysis uses only properly sequenced cases with accurate temporal ordering.
This documentation is part of the mindzie Studio process mining platform.