Activity More Than
Overview
The Activity More Than filter selects cases based on how many times a specific activity was performed. This frequency-based case-level filter identifies cases where a particular activity occurred more than a specified number of times, making it ideal for detecting repetitive work patterns, rework loops, or unusual process behaviors.
Common Uses
- Identify cases with excessive rework or repeated activities
- Find cases where approval loops occurred multiple times
- Detect unusual process patterns with repeated steps
- Analyze cases with multiple review cycles
- Filter for cases requiring repeated customer contacts
- Identify potential process inefficiencies through activity repetition
Settings
Activity Value: Select the activity name to count occurrences of. The dropdown displays all unique activities in your data along with their frequency counts and percentages.
More Than Count: Specify the threshold count. The filter returns cases where the selected activity occurred MORE than this number of times. For example, setting this to 1 returns cases where the activity happened 2 or more times.
Remove Selected Cases: When enabled, inverts the filter logic to exclude matching cases instead of including them.
Examples
Example 1: Finding Rework Cases
Scenario: You want to identify cases where the "Review" activity was performed more than once, indicating potential rework or quality issues.
Settings:
- Activity Value: "Review"
- More Than Count: 1
- Remove Selected Cases: Unchecked
Result:
Cases where "Review" occurred 2 or more times are included. Case #1001 with 3 review activities is included. Case #1002 with 1 review activity is excluded. Case #1003 with 5 review activities is included.
Insights: This reveals which cases required multiple review cycles, often indicating quality issues, incomplete submissions, or process bottlenecks. You can analyze what causes cases to need repeated reviews.
Example 2: Multiple Customer Contacts
Scenario: Your customer service process should ideally resolve issues in a single contact. You want to find cases where "Customer Contact" happened more than twice, indicating escalations or unresolved issues.
Settings:
- Activity Value: "Customer Contact"
- More Than Count: 2
- Remove Selected Cases: Unchecked
Result:
Cases with 3 or more customer contacts are included. This might represent 15% of all cases but consume 40% of customer service resources. These cases warrant investigation for root cause analysis.
Insights: Multiple contacts often indicate first-contact resolution failures. Analyzing these cases can reveal training gaps, system issues, or complex case types requiring specialized handling.
Example 3: Excluding Normal Repetition
Scenario: In your manufacturing process, a "Quality Check" activity legitimately occurs at multiple stages. You want to EXCLUDE cases with many quality checks to focus on cases that bypassed normal quality procedures.
Settings:
- Activity Value: "Quality Check"
- More Than Count: 2
- Remove Selected Cases: Checked
Result:
Cases with 3 or more quality checks are removed. The remaining cases (with 0-2 quality checks) may indicate shortcuts or bypassed quality gates. Case #5001 with 4 quality checks is excluded (normal process). Case #5002 with 1 quality check is kept for investigation.
Insights: By inverting the filter, you identify cases that may have bypassed standard quality procedures, potentially leading to quality issues downstream.
Example 4: Approval Loop Detection
Scenario: Your purchase order process should have one approval per level. You want to find cases where "Manager Approval" occurred more than once, indicating rejected and resubmitted requests.
Settings:
- Activity Value: "Manager Approval"
- More Than Count: 1
- Remove Selected Cases: Unchecked
Result:
Cases requiring multiple manager approvals are identified. Case #7001 with 2 manager approvals had its first request rejected. Case #7002 with 4 manager approvals went through multiple revision cycles.
Insights: Multiple approvals often indicate unclear requirements, budget issues, or communication gaps between requesters and approvers. These cases typically have longer cycle times and higher costs.
Example 5: Threshold-Based Analysis
Scenario: You want to identify extreme cases where any activity occurred more than 10 times, regardless of what activity it is. You'll run this filter multiple times with different activities.
Settings:
- Activity Value: "Data Entry"
- More Than Count: 10
- Remove Selected Cases: Unchecked
Result:
Cases where "Data Entry" happened more than 10 times are flagged as potential data quality issues or system problems. These outlier cases may represent training needs, system errors, or exceptionally complex transactions.
Insights: High activity counts can indicate process problems, training issues, or genuinely complex cases requiring special handling procedures.
Output
This filter operates at the case level based on activity occurrence counts:
- Counts occurrences of the specified activity within each case
- Compares the count against the threshold using greater-than logic
- When "Remove Selected Cases" is unchecked: Returns cases where activity count > threshold
- When "Remove Selected Cases" is checked: Returns cases where activity count <= threshold
- Preserves all case and event attributes for included cases
- Setting threshold to 0 returns cases containing the activity at least once
Use this filter to identify process behaviors based on activity repetition patterns, particularly useful for rework analysis, loop detection, and identifying unusual cases requiring investigation.
This documentation is part of the mindzie Studio process mining platform.