Event Order

Overview

The Event Order filter identifies cases based on sequential relationships between activities. It allows you to find cases where one activity follows another according to specific patterns: directly (with no activities in between), eventually (at any point later in the case), on the same date, or at the same time. This powerful filter is essential for conformance checking, process variant analysis, and detecting whether expected activity sequences actually occurred in your process data.

The filter provides four distinct relationship types to match different analysis needs. You can use it to verify that required sequences happened (like "approval before payment"), find cases that follow or violate standard procedures, or analyze temporal relationships between activities.

Common Uses

  • Conformance Checking: Verify that required activity sequences occur in the correct order (e.g., "Purchase Order" must come before "Goods Receipt").
  • Process Compliance: Ensure that approval activities directly precede execution activities with no intervening steps.
  • Variant Analysis: Identify cases that follow specific process paths by checking if certain activities eventually follow others.
  • Root Cause Investigation: Find cases where problematic sequences occurred (e.g., "Rework" following "Quality Check").
  • Concurrent Activity Detection: Locate cases where activities happened at the same time or on the same date, which may indicate data quality issues or parallel processing.
  • Exception Handling: Discover cases where escalation activities followed regular activities, indicating process problems.

Settings

Activity First: The first activity in the sequence relationship. This is the activity that should occur before the second activity.

Activity Follows: The second activity in the sequence relationship. This is the activity that should follow the first activity according to the selected follow method.

Follow Method: Defines the type of relationship to check between the two activities:

  • Directly Follows: The second activity must immediately follow the first with no activities in between
  • Eventually Follows: The second activity must occur after the first at any point in the case
  • Same Times: Both activities must occur at exactly the same timestamp
  • Same Dates: Both activities must occur on the same calendar date

Remove Filter: When unchecked (default), returns cases that match the follow pattern. When checked, returns cases that do NOT match the pattern, effectively inverting the filter logic.

Attribute Name (optional): Specifies which event attribute column to analyze for activity names. If not provided, uses the default activity column from your event log.

Compare Attribute Name (optional): Adds an additional attribute comparison constraint when using Directly Follows or Eventually Follows methods. This enables more complex filtering scenarios.

Use Date If No Time (optional): When checked, uses date-based sorting for activities that lack time information. Only relevant for Directly Follows and Eventually Follows methods.

Examples

Example 1: Direct Sequence Verification

Scenario: You want to find all purchase orders where goods receipt directly follows the purchase order creation, with no activities in between. This helps identify the smoothest, fastest cases without complications.

Settings:

  • Activity First: "Create Purchase Order"
  • Activity Follows: "Goods Receipt"
  • Follow Method: Directly Follows
  • Remove Filter: Unchecked

Result: Returns only cases where "Goods Receipt" immediately follows "Create Purchase Order" with no intervening activities like approvals, changes, or holds.

Insights: These cases represent the ideal process flow. Comparing their characteristics (supplier, department, value) with cases that have additional steps reveals what factors enable smooth processing.

Example 2: Eventual Relationship Detection

Scenario: You need to verify that all cases with a quality check activity eventually reached the delivery activity, regardless of how many steps occurred between them.

Settings:

  • Activity First: "Quality Check"
  • Activity Follows: "Deliver Order"
  • Follow Method: Eventually Follows
  • Remove Filter: Unchecked

Result: Returns all cases where "Deliver Order" occurred at any point after "Quality Check", even if there were rework, approvals, or other activities in between.

Insights: This confirms that quality-checked items were ultimately delivered. Cases missing from this filter result may indicate incomplete processing or cancelled orders after quality inspection.

Example 3: Compliance Violation Detection

Scenario: You want to find cases where payment occurred without prior approval, which violates company policy. Using the inverted filter helps identify these non-compliant cases.

Settings:

  • Activity First: "Approve Payment"
  • Activity Follows: "Execute Payment"
  • Follow Method: Directly Follows
  • Remove Filter: Checked

Result: Returns cases where "Execute Payment" does NOT directly follow "Approve Payment", indicating either missing approvals or activities between approval and payment.

Insights: These cases represent potential compliance violations requiring investigation. They may reveal auto-payments, emergency processing, or gaps in approval workflows.

Example 4: Same-Day Activity Analysis

Scenario: You want to identify cases where order creation and delivery happened on the same day, which may indicate expedited processing or data quality issues.

Settings:

  • Activity First: "Create Order"
  • Activity Follows: "Deliver Order"
  • Follow Method: Same Dates
  • Remove Filter: Unchecked

Result: Returns cases where both activities occurred on the same calendar date, regardless of the actual time difference.

Insights: Same-day order fulfillment may indicate:

  • Express shipping requests
  • Local deliveries with fast processing
  • Emergency orders with special handling
  • Potential timestamp errors if this pattern is unexpected

Example 5: Concurrent Timestamp Detection

Scenario: You need to find cases where two different systems recorded activities at exactly the same timestamp, which could indicate data quality issues or batch processing.

Settings:

  • Activity First: "System A Update"
  • Activity Follows: "System B Update"
  • Follow Method: Same Times
  • Remove Filter: Unchecked

Result: Returns cases where both activities have identical timestamps down to the second.

Insights: Exact timestamp matches across different activities may reveal:

  • Automated batch processes updating multiple systems
  • Data import issues where timestamps weren't properly recorded
  • Need for more precise timestamp granularity
  • Integration problems between systems

Example 6: Finding Cases Without Expected Sequences

Scenario: You want to identify cases where approval never eventually led to execution, which could indicate cancelled or stuck processes.

Settings:

  • Activity First: "Approve Request"
  • Activity Follows: "Execute Request"
  • Follow Method: Eventually Follows
  • Remove Filter: Checked

Result: Returns cases where "Execute Request" did NOT occur after "Approve Request" at any point in the case.

Insights: These cases represent approved requests that were never executed, potentially indicating:

  • Cancelled approvals
  • Cases stuck after approval
  • Process breakdowns requiring intervention
  • Approved requests awaiting execution

Output

The filter returns a dataset containing only the cases that match (or don't match, if Remove Filter is checked) the specified sequential relationship. All events and attributes for each case are preserved in the filtered results. The number of cases in the output will typically be fewer than the input, as cases not meeting the criteria are removed.

If no cases match the specified sequence relationship, the filter returns an empty result set.

Technical Notes

  • Filter Type: Case-level filter (removes entire cases based on activity relationships)
  • Activity Matching: Uses exact, case-sensitive string matching for activity names
  • Temporal Logic: For Directly Follows and Eventually Follows, activities must exist in chronological order
  • Validation: Automatically suggests similar activity names if specified activities are not found
  • Performance: Optimized for efficient sequence detection even in cases with many activities
  • Both Activities Required: Cases must contain both specified activities to be considered for inclusion (unless using inverted logic)

This documentation is part of the mindzieStudio process mining platform.

An error has occurred. This application may no longer respond until reloaded. Reload ??