Data Template: Generic Process
Your Universal Data Template
- Universal structure that works with any process
- Flexible attributes that adapt to your needs
- Compatible with all major source systems
This is our generic process mining data template. Use our process-specific templates for more specific guidance.
Attributes
| Name | Description | ||
|---|---|---|---|
Activity Activity | The name of the process step or event that occurred. | ||
Description The Activity field identifies what happened at each point in the process. Activities should be named consistently and represent meaningful business events. Why it matters Activity names determine how your process map is visualized and analyzed. Where to get Derive from status changes, action types, or event descriptions in your source system. Examples Case CreatedReview CompletedPayment Processed | |||
Case ID CaseId | Unique identifier for each process instance. | ||
Description The Case ID is the fundamental identifier that connects all events belonging to the same process instance. Every event in your event log must have a Case ID. Why it matters Without a proper Case ID, it's impossible to trace the flow of individual cases through your process. Where to get Use the primary key or reference number from your main transaction table. Examples ORD-2024-001234TKT-98765REQ-0042 | |||
Timestamp StartTime | When the activity started. Must include date and time. | ||
Description The timestamp records when each activity happened. This is essential for calculating cycle times, identifying bottlenecks, and understanding the sequence of events. Why it matters Timestamps enable all time-based analysis including cycle times and bottleneck detection. Where to get Use the most accurate timestamp available from your source system. Examples 2024-03-15T09:30:00Z2024-03-15T14:45:30Z | |||
Case Type CaseType | Category or type of the case being processed. | ||
Description Categorizes cases by type, enabling comparison of different categories. Different case types often have different process paths and performance. Why it matters Segmenting by case type reveals performance differences across categories. Where to get Look for type codes, category fields, or classification attributes. Examples StandardPriorityComplex | |||
Department Department | The organizational unit responsible for the activity. | ||
Description Identifies which department, team, or business unit handled each activity. Useful for analyzing handoffs between teams. Why it matters Cross-departmental analysis reveals handoff delays and organizational friction. Where to get Look for department codes or organizational unit identifiers. Examples FinanceOperationsCustomer Service | |||
End Time EndTime | When the activity ended, if different from start time. | ||
Description The end timestamp records when each activity was completed. Including both start and end times enables calculation of activity duration and processing time. Why it matters End times enable calculation of actual work time versus waiting time. Where to get Look for completion timestamps or status change times indicating activity completion. Examples 2024-03-15T10:15:00Z2024-03-15T16:30:00Z | |||
Priority Priority | Priority level assigned to the case. | ||
Description Indicates the urgency or importance of each case. Priority often affects how quickly cases are processed and which paths they follow. Why it matters Priority analysis validates that urgent cases receive appropriate attention. Where to get Look for priority fields, urgency indicators, or SLA tier assignments. Examples HighMediumLow | |||
User User | The person who performed the activity. | ||
Description Identifies which user or resource performed each activity. This enables resource analysis, workload balancing, and performance comparisons. Why it matters Resource analysis helps identify training needs and workload imbalances. Where to get Look for user IDs, employee numbers, or usernames associated with each event. Examples john.smithEMP-12345user_a1b2c3 | |||
Activity Amount ActivityAmount | Monetary amount associated with this activity. | ||
Description The financial value processed or affected by this activity. Enables value-weighted analysis. Why it matters Value analysis helps prioritize improvements based on financial impact. Where to get Look for transaction amounts, invoice values, or order totals. Examples 1500.0025000.00750.50 | |||
Activity CO2 ActivityCO2 | Carbon footprint of this activity. | ||
Description The carbon emissions associated with this activity. Enables sustainability analysis of your process. Why it matters CO2 tracking supports sustainability goals and environmental reporting. Where to get Calculate from activity type and standard emission factors. Examples 0.10.52.0 | |||
Activity Cost ActivityCost | Cost of performing this activity. | ||
Description The monetary cost associated with performing this activity. Enables cost analysis and identification of expensive process steps. Why it matters Cost analysis helps prioritize improvements based on financial impact. Where to get Look for cost allocation fields or calculate from standard cost tables. Examples 15.0045.50120.00 | |||
Activity FTE ActivityFTE | FTE (full-time equivalent) hours for this activity. | ||
Description The labor effort in FTE hours for this activity. Useful for capacity planning and workload analysis. Why it matters FTE tracking helps with resource planning and capacity management. Where to get Calculate from processing time and standard FTE rates, or extract from time tracking systems. Examples 0.250.51.0 | |||
Automation Cost ActivityAutomationCost | Cost if this activity were automated. | ||
Description The estimated cost of performing this activity through automation. Useful for automation ROI analysis. Why it matters Comparing manual vs automation costs helps build business cases. Where to get Typically assigned from standard cost models for automated processes. Examples 0.502.005.00 | |||
Business Unit BusinessUnit | The business unit associated with the case. | ||
Description Identifies which business unit or division is responsible for or associated with the case. Useful for multi-divisional organizations. Why it matters Business unit analysis reveals cross-organizational performance patterns. Where to get Look for business unit codes, division identifiers, or profit center assignments. Examples RetailEnterpriseSMB | |||
Channel Channel | How the case was initiated or received. | ||
Description Identifies the channel through which the case entered your process. Different channels often have different characteristics and performance. Why it matters Channel analysis reveals which intake methods are most efficient. Where to get Look for source indicators, channel codes, or origin fields. Examples Web PortalEmailPhoneAPI | |||
Country Country | Country associated with the case. | ||
Description Geographic location relevant to the case. Useful for analyzing regional differences in process performance or compliance requirements. Why it matters Geographic analysis reveals regional variations and compliance patterns. Where to get Look for country codes, region identifiers, or location fields. Examples United StatesGermanyJapan | |||
Customer Customer | Customer or party associated with the case. | ||
Description Identifies the customer, client, or external party related to the case. Enables customer-centric analysis of process performance. Why it matters Customer analysis reveals patterns in customer experience. Where to get Look for customer IDs, account numbers, or party identifiers. Examples CUST-001234Acme CorpACC-98765 | |||
Customer Segment CustomerSegment | Segment or tier of the customer. | ||
Description Categorizes customers by segment, tier, or value. Useful for analyzing if different customer segments receive different service levels. Why it matters Segment analysis validates that high-value customers receive appropriate attention. Where to get Look for segment codes, tier assignments, or customer classification fields. Examples EnterpriseSMBConsumer | |||
Is Automated IsAutomated | Whether the activity was performed automatically. | ||
Description Indicates if the activity was automated (by system) or manual (by user). Essential for understanding automation levels. Why it matters Automation analysis reveals opportunities for further automation. Where to get Derive from user type (system vs. human) or automation flags. Examples truefalse | |||
Last Data Update LastDataUpdate | When this record was last updated. | ||
Description The timestamp of the most recent update to this record. Useful for incremental data loading and freshness tracking. Why it matters Update tracking supports incremental loading and data quality monitoring. Where to get Look for last modified timestamps or change tracking fields. Examples 2024-03-15T12:00:00Z2024-03-16T08:30:00Z | |||
Processing Time ProcessingTime | Duration of the activity in minutes or seconds. | ||
Description The time spent actively working on the activity. Can be calculated from start and end times or provided directly if your system tracks it. Why it matters Understanding processing time helps identify which activities consume the most effort. Where to get Calculate from EndTime - StartTime, or extract from system duration fields. Examples 4512015 | |||
Product Product | Product or service associated with the case. | ||
Description Identifies which product, service, or offering is related to the case. Enables product-level analysis of process performance. Why it matters Product analysis reveals if certain products have different process characteristics. Where to get Look for product codes, SKUs, or service identifiers. Examples Product AService Plan ProSKU-12345 | |||
Region Region | Geographic region for the case. | ||
Description A broader geographic grouping than country. Useful for regional analysis when operations span multiple countries. Why it matters Regional analysis helps understand performance across geographic areas. Where to get Look for region codes or derive from country information. Examples EMEAAmericasAPAC | |||
Resource Resource | The resource (person or system) that performed the activity. | ||
Description A generic identifier for whatever performed the activity, whether human or automated. Useful when activities can be performed by either people or systems. Why it matters Resource tracking enables comparison of human vs automated performance. Where to get Look for performer identifiers that may include both users and system accounts. Examples user_123AUTO_SYSTEMbot_processor | |||
SLA State SLAState | Whether the case is within or outside SLA. | ||
Description Indicates if the case is currently meeting its service level agreement. Useful for compliance monitoring and escalation analysis. Why it matters SLA tracking identifies cases at risk and overall compliance rates. Where to get Look for SLA status fields, breach indicators, or calculate from timestamps vs targets. Examples Within SLAAt RiskBreached | |||
Source System SourceSystem | The system where this event originated. | ||
Description Identifies which source system recorded this event. Useful when combining data from multiple systems. Why it matters Source tracking helps understand data lineage and system boundaries. Where to get Add as a constant or derive from the extraction source. Examples SAPSalesforceServiceNow | |||
Team Team | The specific team within a department. | ||
Description A more granular organizational grouping than department. Useful when multiple teams within a department handle different parts of the process. Why it matters Team-level analysis reveals workload distribution and specialization patterns. Where to get Look for team codes, queue identifiers, or group assignments. Examples Team AlphaEscalationsTier 2 Support | |||
Activities
| Activity | Description | ||
|---|---|---|---|
Assigned to Handler | Case is routed to a specific person or team for processing. This assignment determines who is responsible for moving the case forward. | ||
Why it matters Assignment efficiency affects how quickly work begins. Delays here indicate routing or workload issues. Where to get Look for assignment changes, owner modifications, or queue entries in your system. Capture Assignment or owner change timestamp Event type explicit | |||
Case Completed | The case has been successfully completed and closed. This marks the end of the process instance. | ||
Why it matters Essential for calculating cycle time and throughput. The completion rate indicates process effectiveness. Where to get Look for completion timestamps, closed status, or final outcome records. Capture Completion or closure timestamp Event type explicit | |||
Case Created | The initial event that starts a new case in the process. This represents when a new instance of work enters the system, whether triggered by a customer request, an internal need, or an automated event. | ||
Why it matters Marks the official start of the process and is essential for calculating total cycle time and throughput. Where to get Look for creation timestamps, submission dates, or initial status changes in your source system. Capture Creation timestamp from the primary transaction or record Event type explicit | |||
Data Validated | Verification that required information is complete and correct. This may be an automated system check or a manual review by a team member. | ||
Why it matters Early validation prevents downstream issues and rework. Missing this step often correlates with longer cycle times. Where to get Look for validation status changes, verification timestamps, or quality check completions. Capture Status change or validation completion timestamp Event type explicit | |||
Processing Started | Active work on the case begins. This marks the transition from waiting in a queue to actual processing. | ||
Why it matters The gap between assignment and processing started reveals queue wait times and workload issues. Where to get Look for status changes indicating work has begun, first touch timestamps, or activity log entries. Capture First activity after assignment or explicit start timestamp Event type inferred | |||
Review Completed | A review or approval step has been finished. Many processes require one or more reviews before proceeding. | ||
Why it matters Review steps are common bottlenecks. Understanding review duration helps identify approval delays. Where to get Look for approval timestamps, review completions, or sign-off records. Capture Approval or review completion timestamp Event type explicit | |||
Action Executed | A specific action or task within the process has been completed. | ||
Why it matters Individual action tracking helps identify which specific steps contribute most to cycle time. Where to get Look for task completion timestamps, action logs, or step completions. Capture Task or action completion timestamp Event type explicit | |||
Case Cancelled | The case has been cancelled or abandoned before completion. | ||
Why it matters Cancellation patterns reveal issues with process design, customer needs, or upstream problems. Where to get Look for cancellation timestamps, abandoned status, or termination records. Capture Cancellation or termination timestamp Event type explicit | |||
Decision Made | A key decision point in the process has been reached and resolved. | ||
Why it matters Decision points often require authorization and can become bottlenecks. Clear decision trails support compliance. Where to get Look for decision records, approval/rejection flags, or outcome determinations. Capture Decision timestamp or outcome recording Event type explicit | |||
Escalated | The case has been escalated to a higher level or specialized team for handling. | ||
Why it matters Escalations indicate cases that can't be handled through normal channels. High escalation rates suggest training or process issues. Where to get Look for escalation records, tier changes, or transfers to specialist queues. Capture Escalation timestamp or transfer to specialized queue Event type explicit | |||
Exception Raised | An issue or exception has been identified that requires special handling or escalation. | ||
Why it matters Exceptions often lead to rework and delays. Tracking them helps identify root causes and prevention opportunities. Where to get Look for error logs, exception flags, escalation records, or special handling indicators. Capture Exception or error timestamp from system logs Event type explicit | |||
Information Received | The requested additional information has been received and the case can proceed. | ||
Why it matters Response time to information requests significantly impacts cycle time. Quick responses enable faster completion. Where to get Look for response receipts, status changes from pending, or document upload timestamps. Capture Response receipt timestamp or status change from waiting Event type explicit | |||
Information Requested | Additional information has been requested from a customer, vendor, or internal stakeholder. | ||
Why it matters Information requests pause the process and often cause significant delays. Minimizing these improves cycle time. Where to get Look for request communications, status changes to 'pending information', or hold timestamps. Capture Request timestamp or status change to waiting state Event type explicit | |||
Extraction Guides
Extraction methods vary by system. For detailed instructions,