fill blanks in event attribute

Overview

The Fill Blanks in Event Attribute enrichment is a powerful data quality operator that intelligently fills null or blank values in event-level attributes by propagating non-null values forward within each case. This essential data cleanup tool addresses a common data quality issue where event attributes contain incomplete information - such as order statuses, approval states, or tracking numbers that may not be recorded at every process step but should logically persist until they change. The enrichment uses a forward-fill strategy, carrying the last known value forward to subsequent events that have missing or null values.

This enrichment operates at the event level within each case, processing events in chronological order to ensure that blank values inherit the most recent non-null value from previous events in the same case. The forward-fill approach is particularly valuable for state-based attributes where the absence of a value typically means "no change" rather than "no value." By filling these blanks, you create a complete, consistent view of attribute values throughout the case lifecycle, enabling more accurate process analysis, filtering, and reporting without losing the temporal relationship between events.

Common Uses

Complete order status attributes in purchase-to-pay processes where status changes are only recorded when they occur, not repeated at every step
Fill in approval states in workflow processes where approval decisions persist across subsequent activities until the next approval stage
Propagate tracking numbers or reference IDs that are assigned early in the process but needed for analysis throughout all events
Complete product or customer attributes that are captured at order creation but missing from fulfillment and shipping events
Fill shipment carrier information that is determined at dispatch but should be associated with all subsequent tracking events
Maintain project phase or stage attributes across all activities within each phase of project execution
Complete sales representative or team assignments that apply to all events in a case after initial assignment

Settings

Event Attribute Name: Select the event-level attribute that contains blank or null values you want to fill. The dropdown displays all event attributes in your dataset. The enrichment will process each case independently, filling blank values by carrying forward the last known non-null value from previous events within the same case. Only values that are explicitly null or blank are filled - existing non-null values are preserved and used as the basis for filling subsequent blanks. Choose attributes where missing values logically mean "use the previous value" rather than "truly no value," such as status fields, state indicators, or reference codes that persist across multiple activities.

Examples

Example 1: Purchase Order Status Completion

Scenario: An e-commerce company's order processing system records order status changes in an event attribute called "Order_Status," but this attribute is only populated when the status actually changes. Most events have null values for Order_Status, making it impossible to filter or analyze orders by their status at specific process stages.

Event Data Before Enrichment: | Case ID | Activity | Timestamp | Order_Status | Order_Amount | |---------|----------|-----------|--------------|--------------| | PO-1001 | Create Order | 2024-01-10 08:00 | Pending | 1500.00 | | PO-1001 | Credit Check | 2024-01-10 08:15 | null | 1500.00 | | PO-1001 | Approve Order | 2024-01-10 09:30 | Approved | 1500.00 | | PO-1001 | Pick Items | 2024-01-10 10:00 | null | 1500.00 | | PO-1001 | Pack Items | 2024-01-10 11:00 | null | 1500.00 | | PO-1001 | Ship Order | 2024-01-10 14:00 | Shipped | 1500.00 | | PO-1001 | Delivery Confirmed | 2024-01-10 16:00 | null | 1500.00 |

Settings:

Event Attribute Name: Order_Status

Output:

Event Data After Enrichment: | Case ID | Activity | Timestamp | Order_Status | Order_Amount | |---------|----------|-----------|--------------|--------------| | PO-1001 | Create Order | 2024-01-10 08:00 | Pending | 1500.00 | | PO-1001 | Credit Check | 2024-01-10 08:15 | Pending | 1500.00 | | PO-1001 | Approve Order | 2024-01-10 09:30 | Approved | 1500.00 | | PO-1001 | Pick Items | 2024-01-10 10:00 | Approved | 1500.00 | | PO-1001 | Pack Items | 2024-01-10 11:00 | Approved | 1500.00 | | PO-1001 | Ship Order | 2024-01-10 14:00 | Shipped | 1500.00 | | PO-1001 | Delivery Confirmed | 2024-01-10 16:00 | Shipped | 1500.00 |

The enrichment filled null values with the most recent status: "Pending" carries forward to Credit Check, "Approved" carries forward to picking and packing activities, and "Shipped" carries forward to delivery confirmation.

Insights: Now you can accurately filter process maps to show "all picking activities where status was Approved" or calculate performance metrics for approved vs. pending orders at any process stage. The complete status information enables precise bottleneck analysis and compliance checking at every step.

Example 2: Shipment Tracking Number Propagation

Scenario: A logistics company assigns tracking numbers when shipments are created, but their system only records the tracking number in the dispatch event. All subsequent scanning and tracking events have null tracking numbers, preventing end-to-end shipment analysis.

Event Data Before Enrichment: | Case ID | Activity | Timestamp | Tracking_Number | Location | Scanner_ID | |---------|----------|-----------|-----------------|----------|------------| | SHIP-501 | Create Shipment | 2024-01-15 06:00 | null | Warehouse A | SYS001 | | SHIP-501 | Assign to Route | 2024-01-15 06:30 | null | Warehouse A | USER123 | | SHIP-501 | Dispatch | 2024-01-15 07:00 | TRK-789456123 | Warehouse A | SCAN001 | | SHIP-501 | In Transit Scan | 2024-01-15 10:00 | null | Hub Central | SCAN045 | | SHIP-501 | Arrival Scan | 2024-01-15 14:00 | null | Hub East | SCAN089 | | SHIP-501 | Out for Delivery | 2024-01-15 16:00 | null | Branch 12 | SCAN102 | | SHIP-501 | Delivered | 2024-01-15 18:30 | null | Customer | SCAN102 |

Settings:

Event Attribute Name: Tracking_Number

Output:

After enrichment, all events from dispatch onward have the tracking number: | Case ID | Activity | Timestamp | Tracking_Number | Location | Scanner_ID | |---------|----------|-----------|-----------------|----------|------------| | SHIP-501 | Create Shipment | 2024-01-15 06:00 | null | Warehouse A | SYS001 | | SHIP-501 | Assign to Route | 2024-01-15 06:30 | null | Warehouse A | USER123 | | SHIP-501 | Dispatch | 2024-01-15 07:00 | TRK-789456123 | Warehouse A | SCAN001 | | SHIP-501 | In Transit Scan | 2024-01-15 10:00 | TRK-789456123 | Hub Central | SCAN045 | | SHIP-501 | Arrival Scan | 2024-01-15 14:00 | TRK-789456123 | Hub East | SCAN089 | | SHIP-501 | Out for Delivery | 2024-01-15 16:00 | TRK-789456123 | Branch 12 | SCAN102 | | SHIP-501 | Delivered | 2024-01-15 18:30 | TRK-789456123 | Customer | SCAN102 |

Note that the first two events remain null because no tracking number had been assigned yet - the forward-fill only propagates values after they first appear.

Insights: Customer service can now search for any tracking number and see the complete journey including all scan events. Performance analysis can measure handling times at each location with proper tracking number attribution. Exception handling can identify cases where tracking numbers appear at unexpected stages.

Example 3: Healthcare Patient Insurance Status

Scenario: A hospital's patient management system records insurance verification results in an event attribute, but this status only updates when verification occurs or when insurance changes. Most treatment events have null insurance status, making it difficult to analyze treatment patterns by insurance coverage type.

Event Data Before Enrichment: | Case ID | Activity | Timestamp | Insurance_Status | Treatment_Code | Provider | |---------|----------|-----------|------------------|----------------|----------| | PAT-2001 | Registration | 2024-02-01 08:00 | Pending | null | Clerk A | | PAT-2001 | Insurance Verification | 2024-02-01 08:15 | Verified | null | System | | PAT-2001 | Triage Assessment | 2024-02-01 08:30 | null | TRIAGE-01 | Nurse B | | PAT-2001 | Physician Consult | 2024-02-01 09:00 | null | CONSULT-01 | Dr. Smith | | PAT-2001 | Lab Test Order | 2024-02-01 09:30 | null | LAB-CBC | Dr. Smith | | PAT-2001 | Lab Collection | 2024-02-01 10:00 | null | LAB-CBC | Tech C | | PAT-2001 | Insurance Re-verification | 2024-02-01 11:00 | Approved | null | System | | PAT-2001 | Treatment | 2024-02-01 12:00 | null | TX-MINOR | Dr. Jones | | PAT-2001 | Discharge | 2024-02-01 14:00 | null | DISCHARGE | Nurse D |

Settings:

Event Attribute Name: Insurance_Status

Output:

After enrichment, insurance status is complete throughout the patient journey: | Case ID | Activity | Timestamp | Insurance_Status | Treatment_Code | Provider | |---------|----------|-----------|------------------|----------------|----------| | PAT-2001 | Registration | 2024-02-01 08:00 | Pending | null | Clerk A | | PAT-2001 | Insurance Verification | 2024-02-01 08:15 | Verified | null | System | | PAT-2001 | Triage Assessment | 2024-02-01 08:30 | Verified | TRIAGE-01 | Nurse B | | PAT-2001 | Physician Consult | 2024-02-01 09:00 | Verified | CONSULT-01 | Dr. Smith | | PAT-2001 | Lab Test Order | 2024-02-01 09:30 | Verified | LAB-CBC | Dr. Smith | | PAT-2001 | Lab Collection | 2024-02-01 10:00 | Verified | LAB-CBC | Tech C | | PAT-2001 | Insurance Re-verification | 2024-02-01 11:00 | Approved | null | System | | PAT-2001 | Treatment | 2024-02-01 12:00 | Approved | TX-MINOR | Dr. Jones | | PAT-2001 | Discharge | 2024-02-01 14:00 | Approved | DISCHARGE | Nurse D |

Insights: The hospital can now accurately track which treatments occurred under which insurance authorization status. Compliance reporting can verify that all procedures had appropriate insurance approval. Quality analysis can identify delays between insurance verification and treatment initiation.

Example 4: Manufacturing Work Order Priority

Scenario: A manufacturing plant assigns priority levels to work orders, but priority is only recorded when the order is created or when it changes due to customer requests. Production activities don't carry priority information, making it impossible to analyze resource allocation by priority level.

Event Data Before Enrichment: | Case ID | Activity | Timestamp | Priority | Machine | Operator | |---------|----------|-----------|----------|---------|----------| | WO-3005 | Create Work Order | 2024-03-01 06:00 | Normal | null | System | | WO-3005 | Material Allocation | 2024-03-01 07:00 | null | null | Planner A | | WO-3005 | Setup Machine | 2024-03-01 08:00 | null | MC-205 | Tech B | | WO-3005 | Start Production | 2024-03-01 09:00 | null | MC-205 | Operator C | | WO-3005 | Priority Escalation | 2024-03-01 11:00 | Urgent | null | Supervisor | | WO-3005 | Quality Check | 2024-03-01 13:00 | null | QC-12 | Inspector D | | WO-3005 | Finish Production | 2024-03-01 15:00 | null | MC-205 | Operator C | | WO-3005 | Packaging | 2024-03-01 16:00 | null | PKG-08 | Packer E |

Settings:

Event Attribute Name: Priority

Output:

The enrichment propagates priority values forward, showing exactly when priority changed: | Case ID | Activity | Timestamp | Priority | Machine | Operator | |---------|----------|-----------|----------|---------|----------| | WO-3005 | Create Work Order | 2024-03-01 06:00 | Normal | null | System | | WO-3005 | Material Allocation | 2024-03-01 07:00 | Normal | null | Planner A | | WO-3005 | Setup Machine | 2024-03-01 08:00 | Normal | MC-205 | Tech B | | WO-3005 | Start Production | 2024-03-01 09:00 | Normal | MC-205 | Operator C | | WO-3005 | Priority Escalation | 2024-03-01 11:00 | Urgent | null | Supervisor | | WO-3005 | Quality Check | 2024-03-01 13:00 | Urgent | QC-12 | Inspector D | | WO-3005 | Finish Production | 2024-03-01 15:00 | Urgent | MC-205 | Operator C | | WO-3005 | Packaging | 2024-03-01 16:00 | Urgent | PKG-08 | Packer E |

Insights: Production managers can now identify which activities were performed under urgent priority, measure the impact of priority escalations on cycle times, and optimize resource allocation based on real-time priority status at each production stage.

Example 5: Financial Transaction Approval Authority

Scenario: A bank's transaction processing system records the approval authority level (Branch, Regional, Corporate) only when transactions are submitted for approval. Subsequent processing steps have null authority values, preventing analysis of workflow routing by authority level.

Event Data Before Enrichment: | Case ID | Activity | Timestamp | Approval_Authority | Amount | Status | |---------|----------|-----------|-------------------|--------|--------| | TXN-8001 | Initiate Transfer | 2024-04-01 09:00 | null | 250000.00 | Pending | | TXN-8001 | Risk Assessment | 2024-04-01 09:15 | null | 250000.00 | Pending | | TXN-8001 | Route for Approval | 2024-04-01 09:30 | Regional | 250000.00 | Pending | | TXN-8001 | Document Review | 2024-04-01 10:00 | null | 250000.00 | Pending | | TXN-8001 | Compliance Check | 2024-04-01 10:30 | null | 250000.00 | Pending | | TXN-8001 | Regional Approval | 2024-04-01 11:00 | null | 250000.00 | Approved | | TXN-8001 | Execute Transfer | 2024-04-01 11:15 | null | 250000.00 | Completed | | TXN-8001 | Confirmation Sent | 2024-04-01 11:20 | null | 250000.00 | Completed |

Settings:

Event Attribute Name: Approval_Authority

Output:

After enrichment, all events after routing show the authority level: | Case ID | Activity | Timestamp | Approval_Authority | Amount | Status | |---------|----------|-----------|-------------------|--------|--------| | TXN-8001 | Initiate Transfer | 2024-04-01 09:00 | null | 250000.00 | Pending | | TXN-8001 | Risk Assessment | 2024-04-01 09:15 | null | 250000.00 | Pending | | TXN-8001 | Route for Approval | 2024-04-01 09:30 | Regional | 250000.00 | Pending | | TXN-8001 | Document Review | 2024-04-01 10:00 | Regional | 250000.00 | Pending | | TXN-8001 | Compliance Check | 2024-04-01 10:30 | Regional | 250000.00 | Pending | | TXN-8001 | Regional Approval | 2024-04-01 11:00 | Regional | 250000.00 | Approved | | TXN-8001 | Execute Transfer | 2024-04-01 11:15 | Regional | 250000.00 | Completed | | TXN-8001 | Confirmation Sent | 2024-04-01 11:20 | Regional | 250000.00 | Completed |

Insights: The bank can now measure processing times by approval authority level, identify bottlenecks in regional vs. corporate approval workflows, and ensure compliance with authority-level routing policies. Performance dashboards can show average approval times segmented by authority level.

Output

The Fill Blanks in Event Attribute enrichment modifies the selected event attribute in-place, replacing null or blank values with the most recently occurring non-null value from previous events within the same case. The enrichment processes each case independently, ensuring that values never propagate across case boundaries.

Forward-Fill Algorithm: The enrichment processes events in chronological order within each case, maintaining a "last known value" variable. When an event has a non-null value for the selected attribute, that value becomes the new "last known value." When an event has a null or blank value, the enrichment fills it with the current "last known value" if one exists. This forward-fill approach creates a step function where values persist until they explicitly change to a new non-null value.

Handling Null Values: The enrichment only fills values that are explicitly null or blank - it never overwrites existing non-null values, even if they differ from the previous value. If the first few events in a case have null values and no prior value exists to carry forward, those initial null values remain unchanged until the first non-null value appears in a subsequent event.

Case-Level Isolation: Each case is processed completely independently. The enrichment never carries values from one case to another, ensuring data integrity and preventing cross-contamination of attribute values between different cases. When a new case begins, the "last known value" resets to null.

Data Type Preservation: The enrichment maintains the original data type of the attribute being filled. Text values, numbers, dates, and other data types are all handled correctly, ensuring that filled values match the type of the original non-null values.

Event Order Dependency: The enrichment depends on proper event ordering within each case. Events should be sorted by timestamp before applying this enrichment to ensure that values propagate in the correct chronological sequence. If events are not properly ordered, the forward-fill may produce unexpected results.

Use with Other Enrichments: This enrichment should typically be applied early in your enrichment workflow, immediately after any data cleanup operations that affect event ordering. Once blanks are filled, other enrichments and filters can reliably reference the attribute knowing that it contains complete information. The filled attribute can be used in:

Process map filters to show variants by attribute value at specific stages
Calculators that require complete attribute values across all events
Conformance checking that validates attribute values at specific activities
Performance analysis that segments cases by attribute states during different process phases

Performance Impact: The enrichment processes data efficiently by iterating through each case's events exactly once. For large datasets, performance is linear with the number of events. The operation modifies data in memory without creating new attributes, making it memory-efficient.

When Not to Use This Enrichment: This enrichment is designed for state-based attributes where missing values logically mean "no change." Do not use it for:

Measurement attributes where null means "not measured" rather than "use previous value" (temperature readings, quantities)
Event-specific data that genuinely varies per event (activity names, timestamps, resources)
Attributes where null has business meaning distinct from the previous value
Random or independent values that should not propagate (transaction IDs, unique identifiers)

Overview

Common Uses

Settings

Examples

Example 1: Purchase Order Status Completion

Example 2: Shipment Tracking Number Propagation

Example 3: Healthcare Patient Insurance Status

Example 4: Manufacturing Work Order Priority

Example 5: Financial Transaction Approval Authority

Output

See Also