event count

Overview

The Event Count enrichment is a fundamental statistics operator that counts the number of events within each case in your process dataset. This enrichment provides essential metrics for understanding case complexity, process variations, and workload distribution across your business processes. Unlike simple case counting, this operator counts the individual activities or events that make up each case, giving you insights into case granularity and process intensity.

The Event Count enrichment becomes particularly powerful when combined with filters, allowing you to count specific types of events or activities that meet certain criteria. For example, you can count only manual activities, system events, or activities performed by specific resources. This targeted counting enables sophisticated analysis of process behavior patterns and helps identify cases that deviate from normal event frequency distributions.

Common Uses

Process Complexity Analysis: Measure the complexity of individual cases by counting their total number of events
Workload Assessment: Identify cases with unusually high or low event counts to understand workload distribution
Quality Control: Count inspection or review events to ensure compliance with quality standards
Automation Opportunities: Count manual versus automated events to identify automation potential
Performance Benchmarking: Compare event counts across different case types, regions, or time periods
Exception Detection: Identify outlier cases with abnormal event frequencies that may indicate process issues
Resource Planning: Understand event volumes to better allocate resources and capacity

Settings

Filter: Optional filter configuration that allows you to count only specific events that meet defined criteria. When no filter is applied, all events in each case are counted. Use filters to count events based on activity names, timestamps, resources, or any other event attributes. This setting enables targeted analysis such as counting only manual activities, error events, or activities performed during specific shifts.

New Attribute Name: The name of the new case attribute that will store the event count value. This attribute will be added to your case table as an integer field. Choose a descriptive name that clearly indicates what events are being counted, especially when using filters. For example, use "Total_Event_Count" for all events, "Manual_Activity_Count" for filtered manual activities, or "Error_Event_Count" for error-related events.

Examples

Example 1: Total Event Count in Purchase Orders

Scenario: A procurement team needs to understand the complexity of their purchase order processes by counting the total number of events in each case to identify which orders require the most processing effort.

Settings:

Filter: None (count all events)
New Attribute Name: Total_PO_Events

Output: The enrichment creates a new case attribute "Total_PO_Events" containing integer values:

Standard orders: 8-12 events (create, approve, send to vendor, receive goods, invoice, payment)
Complex orders: 25-40 events (multiple approvals, change requests, partial deliveries, disputes)
Rush orders: 5-7 events (streamlined process with fewer steps)

Insights: The analysis reveals that 15% of purchase orders have over 25 events, indicating complex processing. These high-event-count cases correlate with orders requiring multiple vendor negotiations and approval escalations, suggesting opportunities for process simplification.

Example 2: Manual Activity Count in Insurance Claims

Scenario: An insurance company wants to measure the manual effort involved in processing claims by counting only activities performed by human agents, excluding automated system events.

Settings:

Filter: Activity Type equals "Manual" OR Resource Not equals "System"
New Attribute Name: Manual_Activity_Count

Output: The enrichment creates "Manual_Activity_Count" with values representing human touchpoints:

Auto-approved claims: 2-3 manual activities (initial review, final approval)
Standard claims: 6-10 manual activities (review, investigation, adjustment, approval)
Complex claims: 15-25 manual activities (multiple reviews, field investigations, negotiations)
Fraudulent claims: 30+ manual activities (extensive investigation and review cycles)

Insights: Claims with more than 20 manual activities have 3x longer processing times and 2x higher costs. Implementing automated document verification could reduce manual activities by 40% for standard claims.

Example 3: Error Event Tracking in Manufacturing

Scenario: A manufacturing plant needs to count quality control failures and error events in their production process to identify problematic production runs requiring additional attention.

Settings:

Filter: Activity contains "Error" OR Activity contains "Reject" OR Activity contains "Rework"
New Attribute Name: Quality_Issue_Count

Output: The enrichment generates "Quality_Issue_Count" showing error frequency per production batch:

High-quality batches: 0-1 error events
Standard batches: 2-4 error events (minor adjustments)
Problematic batches: 8-15 error events (multiple quality issues)
Failed batches: 20+ error events (significant rework required)

Insights: Batches with more than 10 error events show 90% correlation with specific equipment or shift patterns. Early intervention when error count exceeds 5 events prevents 60% of total batch failures.

Example 4: Customer Interaction Count in Service Desk

Scenario: A service desk wants to measure customer interaction intensity by counting all events where customers directly interact with the support system, excluding internal processing activities.

Settings:

Filter: Resource contains "Customer" OR Activity contains "Customer" OR Activity in ["Email Received", "Chat Started", "Call Logged", "Feedback Submitted"]
New Attribute Name: Customer_Touch_Points

Output: Creates "Customer_Touch_Points" attribute with interaction counts:

Self-service resolution: 1-2 interactions (initial request only)
Standard support: 3-5 interactions (request, clarification, resolution confirmation)
Escalated issues: 8-12 interactions (multiple follow-ups and clarifications)
Critical incidents: 15+ interactions (continuous updates and communications)

Insights: Tickets with more than 8 customer interactions have 70% lower satisfaction scores. Proactive communication after 5 interactions reduces total interaction count by 30% and improves satisfaction.

Example 5: Compliance Check Count in Financial Transactions

Scenario: A bank needs to count the number of compliance and verification activities performed on each transaction to ensure regulatory requirements are met and identify transactions requiring enhanced due diligence.

Settings:

Filter: Activity Type equals "Compliance" OR Activity contains "Verify" OR Activity contains "AML" OR Activity contains "KYC"
New Attribute Name: Compliance_Check_Count

Output: The enrichment produces "Compliance_Check_Count" with verification activity counts:

Standard transactions: 2-3 compliance checks (basic AML, sanctions screening)
High-value transactions: 5-8 compliance checks (enhanced due diligence)
International transfers: 10-15 compliance checks (multi-jurisdiction verification)
Flagged transactions: 20+ compliance checks (full investigation protocol)

Insights: Transactions with fewer than 2 compliance checks pose regulatory risk. Those with more than 15 checks have 5x longer processing time but only 2% result in actual compliance issues, suggesting over-checking in certain scenarios.

Output

The Event Count enrichment creates a single new integer attribute in your case table containing the count of events for each case. The attribute stores whole numbers representing the total number of events that match your filter criteria (or all events if no filter is applied). This attribute has a data type of Int32 with display format set to Number for proper numerical formatting in analyses and dashboards.

The new attribute can be immediately used in:

Filters: Create case filters based on event count ranges (e.g., "High Complexity Cases" where event count > 20)
Calculators: Use the count in mathematical expressions, averages, or statistical calculations
Categorizations: Group cases into complexity categories based on event count thresholds
Visualizations: Display event count distributions in histograms, box plots, or heat maps
Correlations: Analyze relationships between event counts and other case attributes like duration, cost, or outcome
Alerts: Set up monitoring rules based on unusual event count patterns

The event count attribute integrates seamlessly with other mindzie Studio features, enabling you to combine it with duration calculations, cost analyses, and performance metrics for comprehensive process intelligence.

Overview

Common Uses

Settings

Examples

Example 1: Total Event Count in Purchase Orders

Example 2: Manual Activity Count in Insurance Claims

Example 3: Error Event Tracking in Manufacturing

Example 4: Customer Interaction Count in Service Desk

Example 5: Compliance Check Count in Financial Transactions

Output

See Also