Remove Activity With Similar Time

Overview

The Remove Activity with Similar Time filter removes specific activity events from cases when they occur within a defined time window of another activity. This event-level filter is designed to clean process logs by eliminating redundant or duplicate activities that happen too close together in time. You specify which activity to remove, which activity to compare against (or all other activities), and the maximum time difference that triggers removal.

Common Uses

  • Remove duplicate or redundant activities that occur within seconds or minutes of each other
  • Clean logs by eliminating automatic retry events that happen immediately after failures
  • Remove redundant notification events that fire too close to their triggering activities
  • Filter out duplicate data entry activities logged within a short time window
  • Clean up process logs where the same activity was mistakenly logged multiple times
  • Remove follow-up activities that occur too quickly after initial activities

Settings

Activity to Remove: The name of the activity you want to remove from cases.

Activity to Compare To: The reference activity to compare timing against. Leave empty to compare against all other activities.

Duration Threshold: The maximum time difference between events. If the activity to remove occurs within this time window after the reference activity, it will be removed.

Setting Purpose Example Value
Activity to Remove Specifies which activity events to remove "Email Notification"
Activity to Compare To Reference activity for timing comparison "Order Confirmed" or leave empty
Duration Threshold Maximum time gap that triggers removal "00:05:00" (5 minutes)

Examples

Example 1: Removing Duplicate Email Notifications

Scenario: Your order management system sometimes sends duplicate email notifications within minutes of order confirmation. These duplicate "Email Sent" events clutter your process log and don't represent meaningful process steps. You want to remove "Email Sent" events that occur within 5 minutes of the "Order Confirmed" activity.

Settings:

  • Activity to Remove: "Email Sent"
  • Activity to Compare To: "Order Confirmed"
  • Duration Threshold: "00:05:00" (5 minutes)

Result:

Any "Email Sent" event that occurs within 5 minutes after an "Order Confirmed" event in the same case is removed. For example, if Case #12345 has "Order Confirmed" at 10:00:00 AM and "Email Sent" at 10:02:30 AM, the email event is removed. If another case has "Email Sent" at 10:08:00 AM (8 minutes later), that email event is kept because it's outside the 5-minute window.

Insights: This cleans your process log by removing redundant notification events that always follow order confirmation closely. The remaining email events represent legitimate separate communications, while duplicate notifications are filtered out, giving you a cleaner view of actual process flow.

Example 2: Eliminating Automatic Retry Events

Scenario: Your payment processing system automatically retries failed transactions within 30 seconds. These automatic "Retry Payment" events are system-generated and should be removed from analysis, keeping only manual retry attempts that occur later.

Settings:

  • Activity to Remove: "Retry Payment"
  • Activity to Compare To: "Payment Failed"
  • Duration Threshold: "00:00:30" (30 seconds)

Result:

Any "Retry Payment" event occurring within 30 seconds after "Payment Failed" is removed from the log. If Case #PAY-789 has "Payment Failed" at 2:15:00 PM and "Retry Payment" at 2:15:15 PM, the retry is removed. Manual retries attempted hours later remain in the log.

Insights: By filtering out automatic system retries, you can focus on meaningful payment processing steps and manual interventions. This provides accurate cycle times and helps identify cases requiring human intervention versus automatic recovery.

Example 3: Removing Redundant Status Checks

Scenario: Your application logs a "Status Check" activity that sometimes happens immediately after any other activity due to automated monitoring. You want to remove "Status Check" events that occur within 1 second of any other activity, as these are automated system checks rather than meaningful process steps.

Settings:

  • Activity to Remove: "Status Check"
  • Activity to Compare To: (leave empty to compare against all activities)
  • Duration Threshold: "00:00:01" (1 second)

Result:

Any "Status Check" event that occurs within 1 second after any other activity is removed. For example, if Case #APP-456 has "Document Upload" at 11:30:00.000 AM and "Status Check" at 11:30:00.500 AM (500 milliseconds later), the status check is removed. Status checks that occur more than 1 second after the previous activity are retained.

Insights: This eliminates automated system monitoring events that clutter your process log, keeping only intentional status checks initiated by users or scheduled processes. Your process visualization becomes cleaner and more representative of actual business activities.

Example 4: Cleaning Duplicate Data Entry

Scenario: During a data migration, some "Update Customer Info" activities were mistakenly logged twice within the same minute. You want to remove these duplicate update events to clean your historical data.

Settings:

  • Activity to Remove: "Update Customer Info"
  • Activity to Compare To: (leave empty)
  • Duration Threshold: "00:01:00" (1 minute)

Result:

Any "Update Customer Info" event that occurs within 1 minute after any other activity in the same case is removed. This catches duplicate entries that happened during the migration. If Case #CUST-321 has two "Update Customer Info" events at 3:45:00 PM and 3:45:30 PM, the second one is removed.

Insights: This helps clean historical data from migration issues or double-entry errors. By removing near-simultaneous duplicates, you get a more accurate representation of actual customer information updates and cleaner process metrics.

Output

This filter operates at the event level, removing individual events from cases:

  • Only the specified "Activity to Remove" events are affected
  • Events are removed if they occur AFTER reference events within the time threshold
  • Time comparison is directional (only looks at events occurring after reference events)
  • Cases remain in the dataset even if events are removed
  • All other event attributes and properties are preserved
  • If no events match the removal criteria, the original data is returned unchanged

Use this filter to clean process logs by removing redundant, duplicate, or system-generated activities that occur too close in time to meaningful process steps.


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

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