Overview
The Compare Event Attributes for two Activities enrichment performs sophisticated cross-activity attribute matching to determine whether specific event attributes contain the same values across two different activities within each case. This powerful comparison enrichment creates a boolean case attribute that indicates whether the selected attributes match, considering all occurrences of the activities when they appear multiple times. This is essential for validating data consistency, ensuring proper handoffs between process stages, detecting unauthorized modifications, and verifying that critical information flows correctly through your business process.
Unlike simple attribute change detection, this enrichment considers all execution instances when activities occur multiple times in a case. By default, it compares all values from both activities in sorted order. Alternatively, you can compare only distinct values to ignore repetitions and focus on the unique data present at each activity. This flexibility makes the enrichment valuable for both exact matching scenarios and more nuanced consistency checks across complex process variants.
The enrichment is particularly powerful for compliance verification, data integrity validation, and quality assurance scenarios where specific attributes must maintain consistent values between key process milestones. By creating clear boolean indicators, you can quickly filter and analyze cases that fail matching criteria, enabling targeted investigation of data quality issues, process deviations, and potential compliance violations.
Common Uses
- Purchase-to-Pay Matching: Verify that purchase order numbers, vendor IDs, or item descriptions match exactly between goods receipt and invoice receipt activities
- Three-Way Matching: Ensure price, quantity, or product codes are consistent across purchase orders, delivery confirmations, and invoices
- Handoff Validation: Confirm that customer IDs, account numbers, or reference codes remain consistent between departmental transfers
- Audit Trail Verification: Detect cases where approval codes, authorization numbers, or compliance flags change between submission and processing
- Quality Assurance: Validate that product specifications, batch numbers, or quality ratings remain unchanged between production stages
- Contract Compliance: Ensure contract terms, pricing agreements, or service level codes match between contract signing and service delivery
- Healthcare Continuity: Verify that patient identifiers, medication codes, or treatment protocols stay consistent across care transitions
- Financial Reconciliation: Check that transaction amounts, account numbers, or payment methods match between authorization and settlement
Settings
Filter: Apply optional case-level filters to limit the enrichment to specific subsets of your data. Only cases matching the filter criteria will have the comparison performed. Cases excluded by filters will have null values for the output attribute. Use filters to focus analysis on specific process variants, time periods, or organizational units.
New Attribute Name: Specify the name for the boolean case attribute that will store the comparison result. Choose a descriptive name that clearly indicates what is being compared, such as "PO_Vendor_Match" or "Invoice_Price_Consistency". This attribute will be created in your case table and immediately available for filtering and analysis.
Activity 1: Select the first activity that contains the event attribute to compare. This activity represents the initial checkpoint where the attribute value will be captured. All occurrences of this activity within a case will be included in the comparison. Choose an activity that represents an authoritative or original data entry point in your process.
Attribute 1: Choose which event attribute from Activity 1 to include in the comparison. This can be any event-level attribute such as vendor ID, amount, product code, or status. The enrichment will collect all values of this attribute from all occurrences of Activity 1 within each case for comparison.
Activity 2: Select the second activity that contains the event attribute to compare. This activity represents the secondary checkpoint where the attribute value should match. All occurrences of this activity within a case will be included in the comparison. Choose an activity that represents a dependent or downstream process step where consistency is required.
Attribute 2: Choose which event attribute from Activity 2 to compare against Attribute 1. This attribute may have the same name as Attribute 1 or a different name, allowing you to compare equivalent attributes that use different naming conventions across systems. The enrichment will collect all values of this attribute from all occurrences of Activity 2 for comparison.
Use Distinct Values: Enable this option to compare only the unique values from each activity, ignoring duplicates and repetitions. When enabled, the enrichment creates a set of distinct values from each activity before comparison. When disabled (default), all values including duplicates are compared in sorted order. Enable this option when you want to verify that the same set of unique values exists regardless of repetition counts. For example, use distinct values when checking if the same set of product codes appears in both activities, even if quantities differ.
Examples
Example 1: Purchase Order Invoice Matching
Scenario: A procurement department needs to verify that vendor IDs on invoices match the vendor IDs on corresponding purchase orders. This three-way matching validation is critical for preventing payment fraud and ensuring invoices are legitimate.
Settings:
- Filter: (none)
- New Attribute Name: Vendor_ID_Match
- Activity 1: Create Purchase Order
- Attribute 1: Vendor_ID
- Activity 2: Receive Invoice
- Attribute 2: Vendor_ID
- Use Distinct Values: False
Output:
Creates a boolean case attribute Vendor_ID_Match:
- True: All vendor IDs from purchase orders exactly match all vendor IDs from invoices (same values in same quantities)
- False: Vendor IDs differ between purchase orders and invoices
Sample results showing matching analysis: | Case ID | Purchase Orders | Invoices | Vendor_ID_Match | Analysis | |---------|----------------|----------|-----------------|----------| | PO-1001 | VND-523 | VND-523 | True | Perfect match | | PO-1002 | VND-523, VND-523 | VND-523, VND-523 | True | Multiple POs, exact match | | PO-1003 | VND-523 | VND-724 | False | Different vendors | | PO-1004 | VND-523, VND-724 | VND-523, VND-724 | True | Multiple vendors match | | PO-1005 | VND-523 | VND-523, VND-724 | False | Extra invoice vendor |
Insights: The procurement team discovers that 8% of cases have vendor ID mismatches, indicating potential duplicate invoicing or fraud attempts. They implement mandatory verification workflows for all non-matching cases and recover $340,000 in duplicate payments.
Example 2: Product Code Consistency Check
Scenario: A manufacturing company needs to ensure that product codes assigned during order entry match the product codes recorded during quality inspection, preventing shipment of incorrect items to customers.
Settings:
- Filter: [Order_Status] Equals "Completed"
- New Attribute Name: Product_Code_Consistent
- Activity 1: Enter Order
- Attribute 1: Product_Code
- Activity 2: Quality Inspection
- Attribute 2: Inspected_Product_Code
- Use Distinct Values: True
Output:
Creates the Product_Code_Consistent boolean attribute. With distinct values enabled, the enrichment ignores quantity differences and focuses on whether the same unique product codes appear in both activities.
Analysis of product consistency: | Case ID | Ordered Products | Inspected Products | Product_Code_Consistent | |---------|-----------------|-------------------|------------------------| | ORD-501 | PRD-A, PRD-B | PRD-A, PRD-B | True | | ORD-502 | PRD-A, PRD-A, PRD-B | PRD-A, PRD-B | True (distinct match) | | ORD-503 | PRD-A | PRD-C | False | | ORD-504 | PRD-A, PRD-B | PRD-A, PRD-B, PRD-C | False (extra product) |
Insights: Using distinct value comparison, the company identifies that 12% of completed orders have product code mismatches, with most errors occurring during warehouse picking. They redesign the picking process with barcode verification, reducing errors by 85%.
Example 3: Healthcare Medication Reconciliation
Scenario: A hospital needs to verify that medications prescribed during admission match the medications administered during patient care, ensuring patient safety and identifying potential medication errors.
Settings:
- Filter: [Department] Equals "Cardiology"
- New Attribute Name: Medication_Match
- Activity 1: Admission Prescribe
- Attribute 1: Medication_Code
- Activity 2: Administer Medication
- Attribute 2: Medication_Code
- Use Distinct Values: True
Output:
Creates Medication_Match boolean indicating whether the same set of medications was prescribed and administered. Using distinct values allows detection of unauthorized medications regardless of dosing frequency.
Medication reconciliation results: | Patient ID | Prescribed | Administered | Medication_Match | Review Required | |-----------|-----------|--------------|------------------|-----------------| | PT-8001 | MED-101, MED-205 | MED-101, MED-205 | True | No | | PT-8002 | MED-101 | MED-101, MED-303 | False | Yes - Extra med | | PT-8003 | MED-101, MED-205 | MED-101 | False | Yes - Missing med | | PT-8004 | MED-101 | MED-205 | False | Yes - Wrong med |
Insights: The cardiology department discovers 6.5% of patients have medication mismatches, with 3% receiving unauthorized additions. They implement electronic verification at the point of administration, improving patient safety scores by 40%.
Example 4: Financial Transaction Authorization Verification
Scenario: A payment processing company must verify that transaction amounts approved during authorization exactly match the amounts settled during final processing, detecting potential fraud or system errors.
Settings:
- Filter: [Transaction_Type] Equals "Credit Card"
- New Attribute Name: Amount_Authorization_Match
- Activity 1: Authorize Transaction
- Attribute 1: Authorized_Amount
- Activity 2: Settle Transaction
- Attribute 2: Settlement_Amount
- Use Distinct Values: False
Output:
Creates Amount_Authorization_Match boolean. With distinct values disabled, every authorized amount must have a matching settlement amount, including handling cases with multiple authorizations or settlements.
Transaction verification analysis: | Transaction ID | Authorized Amounts | Settled Amounts | Amount_Authorization_Match | |---------------|-------------------|-----------------|---------------------------| | TXN-4001 | 125.00 | 125.00 | True | | TXN-4002 | 125.00, 25.00 | 125.00, 25.00 | True | | TXN-4003 | 125.00 | 150.00 | False | | TXN-4004 | 125.00, 125.00 | 125.00 | False (missing settlement) |
Insights: The company identifies 0.3% of transactions with amount mismatches, representing $2.1M in discrepancies. Analysis reveals a system bug causing decimal rounding errors during currency conversion. The fix prevents future losses and improves customer trust.
Example 5: Quality Control Batch Tracking
Scenario: A pharmaceutical manufacturer needs to ensure that batch numbers recorded during raw material receiving match the batch numbers used during production, maintaining complete traceability for regulatory compliance.
Settings:
- Filter: [Product_Category] Equals "Injectable"
- New Attribute Name: Batch_Traceability_Valid
- Activity 1: Receive Raw Material
- Attribute 1: Material_Batch_Number
- Activity 2: Production Complete
- Attribute 2: Used_Batch_Number
- Use Distinct Values: True
Output:
Creates Batch_Traceability_Valid boolean for regulatory compliance tracking. Distinct values ensure all received batches are accounted for in production regardless of usage frequency.
Batch traceability verification: | Production Run | Received Batches | Used Batches | Batch_Traceability_Valid | Compliance Status | |---------------|-----------------|--------------|-------------------------|-------------------| | RUN-2401 | B-8801, B-8802 | B-8801, B-8802 | True | Compliant | | RUN-2402 | B-8803 | B-8803, B-8803 | True | Compliant (dup OK) | | RUN-2403 | B-8804 | B-8805 | False | Non-compliant | | RUN-2404 | B-8806, B-8807 | B-8806 | False | Missing batch |
Insights: The manufacturer identifies 2.8% of production runs with batch traceability issues, preventing potential FDA compliance violations. They implement real-time batch verification at production start, achieving 99.9% traceability compliance.
Output
The enrichment creates a single boolean case attribute with the name you specify in the "New Attribute Name" setting. This attribute contains:
- True: When the collected values from Activity 1/Attribute 1 exactly match the collected values from Activity 2/Attribute 2
- False: When the values differ in any way (different values, different counts, missing values)
- Empty/Null: When one or both activities are missing from the case, preventing comparison
Matching Logic:
The enrichment uses the following sophisticated comparison algorithm:
- Value Collection: Collects all values of the specified attribute from all occurrences of each activity within the case
- Distinct Processing (if enabled): Removes duplicate values, keeping only unique entries from each activity
- Sorting: Arranges all values in ascending order for consistent comparison
- String Concatenation: Creates pipe-delimited strings of the sorted values (e.g., "|value1|value2|value3")
- Exact Match: Compares the concatenated strings for exact equality
Important Matching Characteristics:
- Order Independent: Values are sorted before comparison, so order doesn't matter
- Null Aware: Null values are treated as distinct values and included in comparison
- Type Sensitive: Comparison is performed on string representations of values
- Count Sensitive (when distinct values disabled): The number of occurrences must match exactly
- Count Insensitive (when distinct values enabled): Only unique values are compared
Handling Multiple Activity Occurrences:
When activities appear multiple times in a case:
- All occurrences contribute their attribute values to the comparison
- With distinct values disabled: Each occurrence's value is included (allowing duplicates)
- With distinct values enabled: Each unique value appears only once regardless of occurrence count
Cases with Missing Activities:
- If Activity 1 or Activity 2 doesn't occur in a case: Output is null (no comparison possible)
- If both activities are missing: Output is null
- If either activity has no value for the specified attribute: Treated as empty string in comparison
Using the Output:
The created boolean attribute is immediately available for:
- Filtering: Show only cases with matching or non-matching values
- Performance Analysis: Calculate match rates and identify patterns in mismatches
- Alert Configuration: Create notifications when critical attributes fail to match
- Root Cause Analysis: Filter to non-matching cases and analyze common characteristics
- Compliance Reporting: Generate reports showing validation pass/fail rates
- Process Mining Visualization: Color-code cases by match status in process maps
- Statistical Analysis: Calculate correlation between matching and other process metrics
- Downstream Enrichments: Use as input to other enrichments and calculators
Example Filter Uses:
Filter to non-matching cases:
[Vendor_ID_Match] Equals False
Filter to valid matching cases only:
[Amount_Authorization_Match] Equals True
Find cases where comparison was possible:
[Product_Code_Consistent] Is Not Empty
The enrichment efficiently processes large event logs by operating at the case level and using optimized sorting and comparison algorithms. Results are cached with your dataset and remain available until you refresh or modify the enrichment configuration.
This documentation is part of the mindzie Studio process mining platform.