Overview
The Case Start filter selects or removes cases based on the value of a specified attribute in the first event of each case. This filter examines the starting point of each case and matches against one or more specific values you define.
This is a case-level filter, which means it evaluates entire cases and either keeps or removes them based on how each case begins. It's particularly useful when you need to analyze processes that started in a particular way, or exclude cases that began with specific conditions.
Common Uses
Analyze cases by initial activity: Select cases that started with specific activities, such as "Order Received" or "Request Submitted", to understand process variations based on how cases begin.
Filter by entry point resource: Identify cases that were initiated by particular teams, departments, or individuals to analyze performance patterns and workload distribution at the process entry point.
Focus on specific order types: Select cases that began with particular order types, customer segments, or priority levels to perform targeted analysis on specific business scenarios.
Exclude problematic starts: Remove cases that started with known problematic activities or conditions, allowing you to focus your analysis on normally-initiated cases.
Compare different process entry points: Analyze how cases that start with different activities behave differently throughout the process lifecycle.
Identify entry channel patterns: Select cases by their initial channel (web, phone, email, in-person) to compare customer journey patterns across different origination points.
Settings
Activity Attribute: Select the event attribute to examine in the first event of each case. Common choices include Activity Name, Resource, or any custom event attribute that exists in your event log. This determines what aspect of the starting event you want to match against.
Attribute Values: Choose one or more specific values from the selected attribute that should match the first event. Cases that begin with any of these values will be selected (or removed if the Remove option is enabled). The dropdown shows available values along with their frequency as starting events.
Remove Selected Cases: Check this box to invert the filter behavior. When enabled, cases that match your criteria will be removed instead of kept, allowing you to focus on cases that did NOT start with the specified values.
Examples
Example 1: Cases Starting with Specific Activity
Scenario: You want to analyze only those purchase order cases that started with the activity "Order Received" to understand the standard process flow, excluding cases that began differently (such as expedited orders or returns).
Settings:
- Activity Attribute: Activity Name
- Attribute Values: Order Received
- Remove Selected Cases: Unchecked
Result: The filter keeps only cases where the first event has Activity Name = "Order Received". If you had 10,000 total cases and 8,500 started with "Order Received", you would now have 8,500 cases (85% of your original data).
Insights: By focusing on standard-entry cases, you can analyze the typical process flow without the complexity introduced by alternative starting points. This is useful for establishing baseline performance metrics and identifying the most common process variant.
Example 2: Excluding Cases by Starting Resource
Scenario: You've discovered that cases started by a specific automated system (Resource: "AutoImport_Bot") have incomplete data in early stages. You want to remove these cases to focus on manually-initiated cases that have complete information.
Settings:
- Activity Attribute: Resource
- Attribute Values: AutoImport_Bot
- Remove Selected Cases: Checked
Result: All cases that started with the resource "AutoImport_Bot" are removed from your analysis. If 1,200 of your 10,000 cases (12%) were started by this bot, you now have 8,800 cases remaining.
Insights: By removing the auto-imported cases, you ensure your analysis focuses on cases with complete early-stage data. This prevents skewed metrics caused by incomplete or differently-structured automated entries and provides more accurate insights into the human-initiated process flow.
Example 3: Multiple Starting Activities
Scenario: Your customer service process has three valid entry points: "Phone Call Received", "Email Received", and "Chat Started". You want to analyze only these standard entries and exclude any cases that started differently (such as escalations or transfers from other departments).
Settings:
- Activity Attribute: Activity Name
- Attribute Values: Phone Call Received, Email Received, Chat Started (select multiple)
- Remove Selected Cases: Unchecked
Result: Only cases that began with one of these three activities are kept. If 9,500 of your 10,000 cases started through these channels, you now have 9,500 cases, excluding the 500 cases that started through non-standard entry points.
Insights: This allows you to focus your analysis on the standard customer service journey while excluding edge cases like internal escalations or transferred cases that don't follow the normal process pattern. You can now establish accurate benchmarks for standard case handling.
Example 4: Analyzing High-Priority Order Starts
Scenario: You want to specifically analyze how high-priority orders are processed differently from regular orders. Your event log has a custom attribute "Priority" that is set in the first event.
Settings:
- Activity Attribute: Priority (custom event attribute)
- Attribute Values: High, Urgent
- Remove Selected Cases: Unchecked
Result: Only cases that started with Priority = "High" or Priority = "Urgent" are kept for analysis. If 2,500 of your 10,000 cases (25%) were high-priority, you now have 2,500 cases to analyze.
Insights: By isolating high-priority cases from the start, you can measure their end-to-end performance separately, identify if they receive preferential treatment, calculate their true cycle times, and ensure that SLAs for urgent orders are being met throughout the entire process.
Output
The Case Start filter produces a refined event log containing only the cases that match (or don't match, if Remove is enabled) your specified starting criteria. Each case in the output has a first event that matches one of your selected attribute values.
What gets filtered: Entire cases are either included or excluded based on their first event. If a case doesn't start with one of your specified values, all events from that case are removed from the analysis.
What stays unchanged: The events within each kept case remain exactly as they were - this filter doesn't modify event details, timing, or sequence. It simply performs a binary decision at the case level.
Percentage information: When configuring the filter, mindzieStudio displays the percentage of cases that start with each available value, helping you understand the impact of your selection before applying the filter.
This documentation is part of the mindzieStudio process mining platform.