duration between two event attributes

Overview

The Duration Between Two Event Attributes enrichment calculates the time difference between two timestamp or timespan fields within the same event record. This powerful enrichment enables you to measure elapsed time between related temporal data points that exist on individual events, such as the time between a scheduled appointment and the actual arrival, or between request submission and approval within a single transaction record.

Unlike enrichments that measure duration across different events in a case, this operator works exclusively at the event level, comparing two datetime or timespan attributes that already exist on each event. This makes it particularly valuable for analyzing delays, lead times, and turnaround metrics where both the start and end timestamps are captured as separate fields in your source system. The enrichment supports both DateTime and TimeSpan attribute types, providing maximum flexibility for diverse timing scenarios.

The enrichment creates a new event-level timespan attribute containing the calculated duration, which can then be used in filters, visualizations, and performance analysis to identify bottlenecks, measure service level compliance, and understand timing variations across your process instances. The calculation is performed as (Attribute Last - Attribute First), enabling both positive durations (when events run late) and negative durations (when events complete early or arrive ahead of schedule).

Common Uses

Calculate appointment delay by measuring time between scheduled appointment time and actual patient arrival time in healthcare processes
Measure approval turnaround by comparing request submission timestamp with approval timestamp on the same transaction record
Track shipping delays by calculating the difference between promised delivery date and actual delivery date
Analyze response time by measuring duration between customer inquiry timestamp and first response timestamp
Evaluate schedule adherence by comparing planned start time with actual start time for maintenance activities
Measure processing efficiency by calculating time between document receipt timestamp and processing completion timestamp
Monitor SLA compliance by measuring time between ticket creation and first response within support ticket records
Track manufacturing schedule variance by comparing planned versus actual production start times

Settings

New Attribute Name: The name of the new event attribute that will store the calculated time difference. This attribute will be created as a TimeSpan data type and will appear in your event table alongside other event attributes. Choose a descriptive name that clearly indicates what duration is being measured, such as "Approval Delay", "Delivery Variance", or "Processing Time". The attribute name should follow your organization's naming conventions and be meaningful when used in filters and visualizations. This field accepts any valid attribute name and becomes the identifier for accessing the calculated duration in subsequent analysis steps.

Attribute Name First: The event attribute containing the earlier timestamp in the duration calculation. This must be an existing DateTime or TimeSpan attribute on your event table. The enrichment will use this as the starting point for the duration measurement. For example, if measuring appointment delays, this would be the "Scheduled Appointment Time" field. The dropdown automatically filters to show only valid DateTime and TimeSpan attributes from your event table, excluding calculated and hidden attributes. This ensures you can only select appropriate temporal data for the calculation.

Attribute Name Last: The event attribute containing the later timestamp in the duration calculation. This must be an existing DateTime or TimeSpan attribute on your event table. The enrichment will use this as the ending point for the duration measurement. For example, if measuring appointment delays, this would be the "Actual Arrival Time" field. The calculation is performed as (Attribute Name Last - Attribute Name First), so ensure you select the chronologically later timestamp here. Positive results indicate the second timestamp occurs after the first (delay or duration), while negative results indicate the second timestamp occurs before the first (early completion).

Examples

Example 1: Healthcare Appointment Delay Analysis

Scenario: A medical clinic wants to measure patient appointment delays by comparing scheduled appointment times with actual arrival times. Both timestamps are recorded in their appointment system as separate fields on each appointment event. Understanding these delays helps optimize scheduling and improve patient satisfaction.

Settings:

New Attribute Name: Appointment Delay
Attribute Name First: Scheduled Time
Attribute Name Last: Actual Arrival Time

Output: The enrichment creates a new event attribute called "Appointment Delay" containing TimeSpan values representing the difference between scheduled and actual times:

Events where patients arrive early will have negative durations (e.g., -00:15:00 for 15 minutes early)
Events where patients arrive on time will have zero or near-zero durations (e.g., 00:02:00 for 2 minutes late)
Events where patients arrive late will have positive durations (e.g., 00:45:00 for 45 minutes late)

Sample data: | Patient ID | Scheduled Time | Actual Arrival Time | Appointment Delay | |------------|----------------|---------------------|-------------------| | P-1001 | 2024-01-15 09:00 | 2024-01-15 09:12 | 00:12:00 | | P-1002 | 2024-01-15 10:30 | 2024-01-15 10:25 | -00:05:00 | | P-1003 | 2024-01-15 14:00 | 2024-01-15 14:38 | 00:38:00 |

Insights: The clinic discovered that 35% of patients arrive more than 15 minutes late for afternoon appointments, leading to schedule cascading delays. They adjusted their scheduling algorithm to add buffer time between afternoon slots, reducing overall wait times by 22%.

Example 2: Purchase Order Approval Turnaround

Scenario: A procurement department needs to measure the time between when a purchase order is submitted and when it receives approval. Both timestamps exist in their ERP system as separate fields on each PO record. Tracking this turnaround time helps identify approval bottlenecks and ensure timely purchasing decisions.

Settings:

New Attribute Name: Approval Turnaround Time
Attribute Name First: Submission DateTime
Attribute Name Last: Approval DateTime

Output: A new event attribute "Approval Turnaround Time" is created showing the elapsed time for each purchase order approval:

Fast approvals: 00:15:30 (15 minutes 30 seconds)
Standard approvals: 1.08:20:00 (1 day, 8 hours, 20 minutes)
Delayed approvals: 5.14:30:00 (5 days, 14 hours, 30 minutes)

Sample data: | PO Number | Amount | Submission DateTime | Approval DateTime | Approval Turnaround Time | |-----------|--------|---------------------|-------------------|--------------------------| | PO-8821 | $450 | 2024-02-10 08:30 | 2024-02-10 09:15 | 00:45:00 | | PO-8822 | $15,200 | 2024-02-10 10:00 | 2024-02-12 14:30 | 2.04:30:00 | | PO-8823 | $89,500 | 2024-02-10 11:20 | 2024-02-16 09:45 | 5.22:25:00 |

Insights: Analysis revealed that purchase orders above $50,000 take an average of 4.5 days for approval, while those under $1,000 are approved in under 2 hours. The organization implemented automated approval workflows for low-value purchases, reducing overall approval time by 40%.

Example 3: Manufacturing Schedule Adherence

Scenario: A manufacturing plant tracks planned start times versus actual start times for production runs. Each production order has both a scheduled start time and an actual start time recorded in their MES (Manufacturing Execution System). Measuring this variance helps identify scheduling accuracy and capacity planning effectiveness.

Settings:

New Attribute Name: Start Time Variance
Attribute Name First: Planned Start Time
Attribute Name Last: Actual Start Time

Output: The "Start Time Variance" attribute shows whether production runs started early (negative), on time (near zero), or late (positive):

Early starts indicate available capacity or schedule flexibility
Late starts reveal scheduling conflicts or upstream delays
Consistent patterns help optimize production planning

Sample data: | Work Order | Product Line | Planned Start Time | Actual Start Time | Start Time Variance | |------------|--------------|-------------------|-------------------|---------------------| | WO-5501 | Line A | 2024-03-05 06:00 | 2024-03-05 06:00 | 00:00:00 | | WO-5502 | Line B | 2024-03-05 08:00 | 2024-03-05 09:45 | 01:45:00 | | WO-5503 | Line C | 2024-03-05 12:00 | 2024-03-05 11:50 | -00:10:00 |

Insights: The plant identified that Line B consistently starts 1-2 hours late due to prolonged changeover times from the previous shift. By implementing parallel changeover activities, they reduced average start time variance from 90 minutes to 15 minutes, increasing daily production capacity by 8%.

Example 4: Customer Support Response Time

Scenario: A customer support organization needs to measure how quickly agents provide their first response to incoming support tickets. Their ticketing system records both the ticket creation timestamp and the first response timestamp as separate fields. Monitoring this response time is critical for SLA compliance and customer satisfaction.

Settings:

New Attribute Name: First Response Time
Attribute Name First: Ticket Created DateTime
Attribute Name Last: First Response DateTime

Output: The enrichment produces a "First Response Time" attribute showing elapsed time to first response for each ticket:

Excellent response: 00:08:30 (8 minutes 30 seconds)
Meeting SLA: 00:55:20 (55 minutes 20 seconds)
SLA breach: 02:15:45 (2 hours 15 minutes 45 seconds)

Sample data: | Ticket ID | Priority | Created DateTime | First Response DateTime | First Response Time | |-----------|----------|------------------|-------------------------|---------------------| | TKT-9001 | High | 2024-04-12 10:22 | 2024-04-12 10:30 | 00:08:00 | | TKT-9002 | Medium | 2024-04-12 11:15 | 2024-04-12 12:05 | 00:50:00 | | TKT-9003 | Low | 2024-04-12 14:30 | 2024-04-12 16:55 | 02:25:00 |

Insights: The support team discovered that high-priority tickets average 12 minutes to first response, well within their 30-minute SLA, but medium-priority tickets average 75 minutes against a 60-minute target. They adjusted their triage process and staffing levels to prioritize medium-priority tickets, improving SLA compliance from 78% to 94%.

Example 5: Logistics Delivery Performance

Scenario: A logistics company needs to analyze delivery performance by comparing promised delivery dates with actual delivery dates. Both dates are captured in their shipment tracking system at the time of order creation and delivery confirmation. Understanding delivery variance helps identify carrier performance issues and improve customer expectations.

Settings:

New Attribute Name: Delivery Variance
Attribute Name First: Promised Delivery Date
Attribute Name Last: Actual Delivery Date

Output: The "Delivery Variance" attribute indicates whether deliveries were early (negative), on time (zero or small positive), or late (positive):

Early deliveries: -1.00:00:00 (1 day early)
On-time deliveries: 00:00:00 to 04:00:00 (on time to 4 hours late)
Late deliveries: 2.08:30:00 (2 days 8 hours 30 minutes late)

Sample data: | Shipment ID | Carrier | Promised Delivery | Actual Delivery | Delivery Variance | |-------------|---------|------------------|-----------------|-------------------| | SHP-7701 | FastShip | 2024-05-20 17:00 | 2024-05-20 15:30 | -01:30:00 | | SHP-7702 | QuickCargo | 2024-05-21 12:00 | 2024-05-21 11:45 | -00:15:00 | | SHP-7703 | StandardPost | 2024-05-22 10:00 | 2024-05-24 14:20 | 2.04:20:00 |

Insights: Analysis revealed that 18% of deliveries were more than 1 day late, with StandardPost accounting for 65% of these delays. The company renegotiated service levels with carriers and implemented a dynamic carrier selection algorithm based on historical performance, reducing late deliveries from 18% to 7% and improving customer satisfaction scores by 15 points.

Output

The Duration Between Two Event Attributes enrichment creates a single new event-level attribute with the following characteristics:

Data Type: TimeSpan - The new attribute stores duration values in TimeSpan format, representing the time difference between the two selected attributes. TimeSpan values can be positive (when the second timestamp is later), negative (when the second timestamp is earlier), or zero (when both timestamps are identical).

Attribute Location: The new attribute is added to the event table and appears alongside other event attributes in your dataset. It is marked as a derived attribute and will be visible in event filters, event attribute lists, and can be aggregated to case level using statistical enrichments.

Calculation Method: For each event, the enrichment calculates: (Attribute Name Last - Attribute Name First). If either source attribute is null or missing for a particular event, the new attribute will remain null for that event, ensuring data integrity without creating false zero values.

Display Format: The TimeSpan values are displayed in standard duration format (days.hours:minutes:seconds). For example:

00:15:30 represents 15 minutes and 30 seconds
1.08:20:00 represents 1 day, 8 hours, and 20 minutes
-00:05:00 represents negative 5 minutes (earlier arrival)

Integration with Other Features: The calculated duration attribute can be used in multiple ways:

Event Filters: Filter events based on duration thresholds (e.g., show only events where response time exceeds 1 hour)
Case Aggregations: Use Sum, Average, Min, or Max enrichments to aggregate event-level durations to case level
Performance Analysis: Visualize duration distributions in charts and identify outliers
Calculators: Reference the duration in custom calculator expressions for complex business logic
Conformance Checking: Define conformance rules based on acceptable duration ranges

Dependencies: The enrichment depends on the two source attributes specified in the configuration. If either source attribute is renamed, hidden, or removed from the dataset, the calculated duration attribute will need to be reconfigured or may become invalid. The enrichment tracks these dependencies and will warn users if source attributes are modified.

Performance Considerations: This enrichment performs a simple subtraction operation for each event and has minimal performance impact, even on large datasets with millions of events. The calculation is executed once when the enrichment is run and the results are stored, so subsequent analysis operations reference the pre-calculated values without recalculation overhead.

Overview

Common Uses

Settings

Examples

Example 1: Healthcare Appointment Delay Analysis

Example 2: Purchase Order Approval Turnaround

Example 3: Manufacturing Schedule Adherence

Example 4: Customer Support Response Time

Example 5: Logistics Delivery Performance

Output

See Also