Overview
The Durations Between a Case Attribute and Activity Times enrichment calculates the time difference between a case-level timestamp attribute and each individual event's activity time within that case. This powerful enrichment creates a new event attribute that shows how much time has elapsed between a fixed reference point (such as order date, contract start date, or due date) and each activity in the process. This enables detailed analysis of how activities relate to important business deadlines, milestones, or baseline dates.
Unlike enrichments that measure time between activities, this operator uses a case-level timestamp as the anchor point for all duration calculations. This is particularly valuable when you need to understand how each step in your process relates to a critical business date, such as measuring all activities against a service level agreement deadline, tracking progress from a project start date, or analyzing how activities cluster around a payment due date. The enrichment supports both forward calculations (time since the reference date) and backward calculations (time until the reference date), with flexible time unit options ranging from seconds to years.
Common Uses
- Track time elapsed from order placement date to each fulfillment activity in the order-to-cash process
- Measure how many days before or after a payment due date each collection activity occurs
- Monitor time from patient admission date to each medical procedure in healthcare processes
- Calculate days from contract signature to each milestone delivery in project management
- Analyze how long after case creation each customer service interaction happens
- Measure time from production start date to each quality check or manufacturing step
- Track days from loan application date to each approval or verification activity
Settings
New Attribute Name: The name for the new event attribute that will store the calculated durations. This attribute will be created at the event level, meaning each event in a case will have its own duration value calculated from the case attribute. Choose a descriptive name that clearly indicates what is being measured, such as "Days_Since_Order_Date", "Hours_Until_Due_Date", or "Time_From_Contract_Start". The name must be unique and not already exist in your dataset.
Attribute Name: The case-level timestamp attribute to use as the reference point for all duration calculations. This dropdown lists all available DateTime attributes from your case table. Select the attribute that represents your business reference date, such as "Order_Date", "Due_Date", "Contract_Start_Date", or "SLA_Deadline". Only DateTime type attributes are available for selection, ensuring valid timestamp comparisons.
Duration Type: Specifies the unit of time for the duration calculation. Options include:
- TimeSpan: Preserves the full time duration with days, hours, minutes, and seconds (displayed as "2d 14:30:45")
- Seconds: Total number of seconds between timestamps
- Minutes: Total number of minutes (useful for short processes)
- Hours: Total number of hours (ideal for same-day or multi-day processes)
- Days: Total number of days (most common for business processes)
- Weeks: Total number of weeks (useful for longer-running processes)
- Months: Approximate number of months (calculated as days/30.44)
- Years: Number of years (for very long-running processes)
Attribute Should Come First: Controls the direction of the duration calculation. When checked (default), the calculation is "event time minus case attribute time", producing positive values when events occur after the reference date. When unchecked, the calculation is reversed to "case attribute time minus event time", producing positive values when events occur before the reference date. Use the default setting to measure time elapsed since a start date, or uncheck to measure time remaining until a deadline.
Allow Fractional Periods: Determines whether duration values can include decimal places. When unchecked (default), durations are rounded down to whole numbers (e.g., 3 days instead of 3.7 days). When checked, durations preserve decimal precision (e.g., 3.7 days, 2.5 hours). Enable this for more precise calculations when analyzing detailed time metrics or when small time differences matter. Keep it disabled for cleaner reporting when whole units are sufficient.
Examples
Example 1: Order Fulfillment Time Tracking
Scenario: An e-commerce company wants to track how long each fulfillment step takes from the original order placement date to identify bottlenecks in their order-to-cash process.
Settings:
- New Attribute Name: Days_Since_Order
- Attribute Name: Order_Date
- Duration Type: Days
- Attribute Should Come First: Checked (true)
- Allow Fractional Periods: Unchecked (false)
Output: The enrichment creates a new event attribute "Days_Since_Order" showing whole number of days from order placement: | Activity | Activity Time | Order_Date | Days_Since_Order | |----------|--------------|------------|------------------| | Order Placed | 2024-01-15 09:00 | 2024-01-15 | 0 | | Payment Verified | 2024-01-15 14:00 | 2024-01-15 | 0 | | Picked | 2024-01-16 10:00 | 2024-01-15 | 1 | | Packed | 2024-01-16 15:00 | 2024-01-15 | 1 | | Shipped | 2024-01-17 08:00 | 2024-01-15 | 2 | | Delivered | 2024-01-19 16:00 | 2024-01-15 | 4 |
Insights: The company can now easily filter for orders where "Days_Since_Order" exceeds their 3-day fulfillment SLA at the shipping stage, identifying which activities cause delays.
Example 2: Payment Collection Before Due Date
Scenario: A financial services company needs to analyze their collection activities in relation to payment due dates, understanding which activities happen proactively versus reactively.
Settings:
- New Attribute Name: Days_Until_Due_Date
- Attribute Name: Payment_Due_Date
- Duration Type: Days
- Attribute Should Come First: Unchecked (false)
- Allow Fractional Periods: Checked (true)
Output: The enrichment creates "Days_Until_Due_Date" showing decimal days until the due date (positive) or days overdue (negative): | Activity | Activity Time | Payment_Due_Date | Days_Until_Due_Date | |----------|--------------|------------------|---------------------| | Invoice Sent | 2024-02-01 | 2024-02-15 | 14.0 | | Reminder Email | 2024-02-10 | 2024-02-15 | 5.0 | | Phone Call | 2024-02-14 | 2024-02-15 | 1.0 | | Payment Received | 2024-02-16 | 2024-02-15 | -1.0 | | Late Fee Applied | 2024-02-20 | 2024-02-15 | -5.0 |
Insights: Positive values indicate proactive collection efforts, while negative values show reactive measures after the due date, helping optimize collection strategies.
Example 3: Patient Treatment Timeline in Healthcare
Scenario: A hospital wants to track all treatment activities relative to patient admission time to ensure timely care delivery and identify delays in critical treatments.
Settings:
- New Attribute Name: Hours_Since_Admission
- Attribute Name: Admission_DateTime
- Duration Type: Hours
- Attribute Should Come First: Checked (true)
- Allow Fractional Periods: Checked (true)
Output: The enrichment produces "Hours_Since_Admission" with precise decimal hour values: | Activity | Activity Time | Admission_DateTime | Hours_Since_Admission | |----------|--------------|-------------------|----------------------| | Emergency Admission | 2024-03-10 14:30 | 2024-03-10 14:30 | 0.0 | | Triage Assessment | 2024-03-10 14:45 | 2024-03-10 14:30 | 0.25 | | Blood Test Ordered | 2024-03-10 15:15 | 2024-03-10 14:30 | 0.75 | | Doctor Consultation | 2024-03-10 16:00 | 2024-03-10 14:30 | 1.5 | | Treatment Started | 2024-03-10 17:30 | 2024-03-10 14:30 | 3.0 | | Patient Discharged | 2024-03-11 09:00 | 2024-03-10 14:30 | 18.5 |
Insights: The hospital can set thresholds for critical activities (e.g., triage within 0.5 hours, treatment within 4 hours) and monitor compliance across all emergency cases.
Example 4: Manufacturing Lead Time Analysis
Scenario: A manufacturer needs to measure each production step against the planned production start date to optimize their manufacturing schedule and identify process inefficiencies.
Settings:
- New Attribute Name: Production_Days
- Attribute Name: Planned_Start_Date
- Duration Type: Days
- Attribute Should Come First: Checked (true)
- Allow Fractional Periods: Unchecked (false)
Output: The enrichment creates "Production_Days" showing whole days from planned start: | Activity | Activity Time | Planned_Start_Date | Production_Days | |----------|--------------|-------------------|-----------------| | Material Received | 2024-04-01 | 2024-04-03 | -2 | | Production Started | 2024-04-03 | 2024-04-03 | 0 | | Assembly Complete | 2024-04-05 | 2024-04-03 | 2 | | Quality Check 1 | 2024-04-06 | 2024-04-03 | 3 | | Rework | 2024-04-07 | 2024-04-03 | 4 | | Quality Check 2 | 2024-04-08 | 2024-04-03 | 5 | | Packaging | 2024-04-09 | 2024-04-03 | 6 |
Insights: Negative values indicate early material arrival, while the progression shows a 6-day production cycle with rework adding 2 extra days, highlighting quality issues.
Example 5: Project Milestone Tracking
Scenario: A consulting firm tracks all project activities against the contract signature date to ensure deliverables align with contractual timelines and identify schedule risks.
Settings:
- New Attribute Name: Weeks_From_Contract
- Attribute Name: Contract_Signed_Date
- Duration Type: Weeks
- Attribute Should Come First: Checked (true)
- Allow Fractional Periods: Checked (true)
Output: The enrichment generates "Weeks_From_Contract" with decimal week values: | Activity | Activity Time | Contract_Signed_Date | Weeks_From_Contract | |----------|--------------|---------------------|-------------------| | Contract Signed | 2024-01-01 | 2024-01-01 | 0.0 | | Kickoff Meeting | 2024-01-03 | 2024-01-01 | 0.29 | | Requirements Gathered | 2024-01-15 | 2024-01-01 | 2.0 | | Design Approved | 2024-01-29 | 2024-01-01 | 4.0 | | Development Started | 2024-02-05 | 2024-01-01 | 5.0 | | Testing Complete | 2024-03-04 | 2024-01-01 | 9.0 | | Delivery | 2024-03-11 | 2024-01-01 | 10.0 |
Insights: The firm can compare actual milestone timing against contracted schedules, with the 10-week total duration helping validate future project estimates and resource planning.
Output
The enrichment creates a new event-level attribute containing the calculated duration between the specified case attribute and each event's activity time. The attribute type depends on your Duration Type selection: TimeSpan type for the TimeSpan option (preserving full time precision), Integer type for whole number durations when fractional periods are disabled, or Float type for decimal durations when fractional periods are enabled.
Each event in the dataset receives its own duration value, calculated individually based on its activity timestamp. The calculation respects the "Attribute Should Come First" setting to determine whether durations are positive (events after the reference date) or negative (events before the reference date). When dates have no time component (midnight timestamps), the enrichment automatically uses date-only arithmetic for cleaner day calculations.
The new attribute integrates seamlessly with other mindzieStudio features. Use it in filters to identify events occurring within specific time windows (e.g., "Show all activities occurring more than 5 days after order date"). Combine it with calculators to compute average durations, identify outliers, or create duration-based KPIs. The attribute can also serve as input for other enrichments, such as categorizing events into time buckets or identifying cases with unusual timing patterns.
This documentation is part of the mindzie Studio process mining platform.