> Continuous Process Improvement > Incident Management > Bmc Helix > Data Template

Data Template: Incident Management

Bmc Helix

Incident Management Attributes (19) Incident Management Activities (14) Extraction Guides (2)

Your Incident Management Data Template

This template provides a clear roadmap for collecting the essential data needed to analyze and optimize your Incident Management process in Bmc Helix. It outlines the crucial attributes and activities to track, along with practical guidance on data extraction. By following this template, you will ensure a comprehensive and accurate foundation for process discovery and improvement.

Recommended attributes to collect
Key activities to track
Extraction guidance for Bmc Helix

New to event logs? Learn how to create a process mining event log.

Download Template

Incident Management Attributes

These are the recommended data fields to include in your event log for comprehensive analysis of your Incident Management process.

5 Required 7 Recommended 7 Optional

	Name	Description
	Activity ActivityName	The name of the specific action or event that occurred at a point in the incident's lifecycle.
Description The Activity Name describes a step in the incident management process, such as 'Incident Categorized', 'Assigned to Support Group', or 'Incident Resolved'. These activities form the nodes in the discovered process map. Analyzing the sequence and frequency of these activities is central to process mining. It helps uncover the actual process flow, identify bottlenecks between steps, detect deviations from the standard operating procedure, and measure the duration of specific stages within the incident lifecycle. Why it matters This attribute defines the steps in the process, enabling the visualization of the process map and the analysis of flows, bottlenecks, and deviations. Where to get Typically derived from status changes, audit logs, or specific event records associated with the incident in the 'HPD:HelpDesk_AuditLogSystem' or similar audit tables. Examples Incident ReportedAssigned to Support GroupInvestigation StartedIncident ResolvedIncident Closed
	Incident ID IncidentId	The unique identifier for each reported incident, serving as the primary key for tracking the incident's lifecycle.
Description The Incident ID is the cornerstone of incident management analysis. It uniquely identifies each case, allowing for the aggregation of all related events, status changes, and activities into a single, cohesive process instance. In process mining, this ID links every step, from 'Incident Reported' to 'Incident Closed', enabling a complete end-to-end view of the incident's journey. It is essential for calculating case-level metrics such as total resolution time, number of reassignments, and identifying process variants. Why it matters This attribute is the fundamental case identifier, making it possible to trace the entire lifecycle of an incident and analyze its flow through the management process. Where to get This is a core field in the primary Incident Management module or form, often labeled as 'Incident Number' or 'Incident ID'. Examples INC000012345678INC000009876543INC000011223344
	Start Time EventTimestamp	The precise date and time when a specific activity or event occurred for an incident.
Description The Event Timestamp records the moment each activity took place. This temporal data is critical for ordering events chronologically and constructing the process flow accurately. In analysis, timestamps are used to calculate durations between activities, measure the total cycle time of incidents, and identify delays or waiting times in the process. Comparing timestamps against service level agreements (SLAs) is also essential for performance monitoring and compliance checks. Why it matters Timestamps provide the chronological order of events and are essential for all time-based analysis, including performance measurement, bottleneck identification, and SLA compliance. Where to get This information is found in the audit log tables, such as 'HPD:HelpDesk_AuditLogSystem', corresponding to each logged action or status change. Examples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data for this record was refreshed from the source system.
Description This attribute provides the timestamp of the most recent data extraction. It is a metadata field that is essential for understanding the freshness of the data being analyzed. Knowing when the data was last updated helps analysts and business users trust the insights derived from the process mining tool. It confirms whether the analysis reflects the most current state of operations or is based on older data. Why it matters Ensures transparency about data freshness, which is critical for making timely and accurate business decisions based on the process analysis. Where to get This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process. Examples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Source System SourceSystem	The system from which the incident data was extracted.
Description This attribute identifies the origin of the data, which is crucial in environments where data from multiple systems is consolidated for analysis. It helps ensure data lineage and provides context for the data's structure and content. For Bmc Helix, this would typically be a static value identifying the specific instance or environment, for example 'BmcHelix_Production'. It is useful for filtering and segmenting data if multiple source systems are ever integrated. Why it matters Provides traceability and context for the data's origin, which is important for data governance and troubleshooting in multi-system environments. Where to get This is typically a static value added during the data extraction, transformation, and loading (ETL) process to identify the data source. Examples BmcHelixBmcHelix_Prod_EUITSM_Platform_A
	Assigned Agent AssignedAgent	The individual support agent assigned to handle the incident.
Description The Assigned Agent is the specific person responsible for the incident at a given time. This provides a more granular level of detail than the support group, enabling analysis of individual performance and workload. This attribute is essential for the 'Team Workload Distribution' dashboard and the 'Activity Volume per Agent StdDev' KPI. By analyzing the volume and types of incidents handled by each agent, managers can identify overburdened individuals, ensure equitable workload distribution, and spot coaching opportunities. Why it matters Enables granular analysis of individual workload and performance, helping to optimize resource allocation and identify top performers or those needing support. Where to get A standard field on the 'HPD:Help Desk' form, commonly named 'Assignee'. Examples Alice SmithBob JohnsonCharlie Brown
	Assigned Support Group AssignedSupportGroup	The support team or group responsible for working on the incident.
Description This attribute identifies the team assigned to an incident. As an incident progresses, it may be reassigned to different support groups, such as the Service Desk, Network Team, or Application Support. Tracking changes in this attribute is fundamental for the 'Incident Reassignment Analysis' dashboard. It allows for visualizing handoffs between teams, measuring the number of transfers per incident, and identifying bottlenecks or knowledge gaps that lead to excessive reassignments. It also supports workload distribution analysis across teams. Why it matters This attribute is key to analyzing team performance, workload distribution, and the efficiency of incident routing and handoffs. Where to get A standard field on the 'HPD:Help Desk' form, typically named 'Assigned Group'. Examples Service DeskNetwork OperationsDatabase AdministrationApplication Support Tier 2
	Incident Category IncidentCategory	The classification of the incident, typically organized in a hierarchical structure.
Description Incident Category provides a structured way to classify incidents based on the affected service, component, or type of issue, for example 'Hardware', 'Software', or 'Network'. This categorization is crucial for routing incidents to the correct team and for later analysis of incident trends. The 'Incident Categorization Accuracy' dashboard relies on this attribute, often comparing its initial value to its value upon resolution to measure the quality of initial triage. Accurate categorization helps in identifying recurring problems and enables more effective problem management. Why it matters Proper categorization is vital for efficient routing, trend analysis, and assessing the accuracy of the initial diagnosis. Where to get These are standard fields on the 'HPD:Help Desk' form, often a set of cascading fields like 'Categorization Tier 1', 'Categorization Tier 2', etc. Examples Software > Enterprise Apps > ERPHardware > Laptop > KeyboardNetwork > Connectivity > Wi-Fi
	Incident Status IncidentStatus	The current or historical state of the incident within its lifecycle, such as 'New', 'In Progress', or 'Closed'.
Description The Incident Status indicates the stage of an incident at any given time. It is often the source for generating the 'Activity' log, where a change in status corresponds to a process step. Analyzing the status allows for filtering incidents by their current state, understanding how much time is spent in different statuses, and identifying incidents that are stuck. For example, a dashboard could highlight incidents that have been in a 'Pending' status for an unusually long time. Why it matters It provides a snapshot of an incident's progress and is crucial for identifying stalled incidents and analyzing time spent in various stages. Where to get A core field on the main incident form, typically 'HPD:Help Desk'. The field is often named 'Status'. Examples NewAssignedIn ProgressPendingResolvedClosed
	Priority Priority	The priority level of the incident, which determines the required speed of resolution.
Description Priority is a key attribute that dictates the urgency of an incident. It is often derived from the incident's impact and urgency and is used to allocate resources and define service level agreement (SLA) targets. In process mining analysis, priority is used to segment incidents to compare the process flows of high-priority versus low-priority cases. This helps verify whether critical incidents are truly being handled faster and identify any deviations in their process paths, which is essential for the 'High-Priority Incident Performance' dashboard and related KPIs. Why it matters This attribute is critical for segmenting analysis to ensure that high-urgency incidents are handled according to defined procedures and SLAs. Where to get A standard field on the 'HPD:Help Desk' form, typically named 'Priority'. Examples CriticalHighMediumLow
	Severity Severity	The measure of the incident's business impact.
Description Severity defines how significantly an incident affects business operations. It is a critical input, along with urgency, for determining the incident's priority and associated SLAs. Analyzing incidents by severity helps in understanding the process performance for the most impactful issues. It is used in dashboards like the 'Critical SLA Breach Overview' to categorize and focus on incidents that pose the greatest risk to the business. Why it matters Severity helps quantify the business impact of incidents, allowing for analysis focused on mitigating the most significant operational risks. Where to get Consult Bmc Helix documentation. This is often a standard field on the incident form, possibly named 'Impact' or 'Severity'. Examples 1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
	SLA Status SLAStatus	Indicates whether the incident is within its service level agreement (SLA) targets or has breached them.
Description The SLA Status provides a clear indicator of service performance for each incident. It typically shows states like 'Within Target', 'Warning', or 'Breached'. This is often a dynamically calculated field within Bmc Helix itself. This attribute is essential for the 'Critical SLA Breach Overview' dashboard and the 'Critical Incident SLA Breach Rate' KPI. It allows for immediate identification and prioritization of incidents that are failing to meet service commitments, enabling a focused analysis on the causes of delays. Why it matters Directly measures performance against commitments and is fundamental for compliance monitoring and identifying processes that cause SLA breaches. Where to get This is often a computed field within Bmc Helix, derived from the incident's priority and age. The status may be stored in a related SLA management module. Examples Within TargetWarningBreached
	Business Service BusinessService	The business service or application affected by the incident.
Description This attribute links an incident to a specific business service defined in the Configuration Management Database (CMDB), such as 'Email Service' or 'ERP System'. Analyzing incidents by the affected business service is crucial for understanding the impact on the organization. It helps prioritize problem management efforts on services that generate the most incidents or suffer the most downtime. This view is essential for reporting on IT's performance from a business-centric standpoint. Why it matters Connects technical incidents to their business impact, enabling analysis that prioritizes work based on what is most critical to the organization. Where to get This is a Configuration Item (CI) field on the incident form, which links to the CMDB. The field might be labeled 'Service' or 'CI'. Examples Corporate Email ServiceSAP ERP FinancialsCustomer Relationship Management
	Channel Channel	The method or channel through which the incident was reported.
Description The Channel attribute specifies how an incident was initiated, for example, via phone call, email, self-service portal, or automated monitoring. Analyzing the process by channel can reveal important differences in resolution times or process paths. For instance, incidents reported via the self-service portal might be resolved faster due to better initial data quality. This analysis can inform decisions about which channels to promote or improve. Why it matters Helps understand how the reporting method impacts the incident lifecycle, revealing opportunities to optimize specific channels for efficiency. Where to get A standard field on the 'HPD:Help Desk' form, often named 'Reported Source'. Examples EmailPhoneSelf-service PortalSystem Monitoring
	Is Reopened IsReopened	A flag that indicates if an incident has been reopened after being resolved.
Description This calculated attribute is a boolean flag that is true if an incident has a 'Incident Reopened' activity in its history. A high rate of reopened incidents can signal issues with the quality of resolutions or premature closing of tickets. This flag is used directly in calculating the 'Incident Re-opening Rate' KPI and for the 'Incident Re-opening Rate Trend' dashboard. It allows analysts to easily filter for and investigate reopened incidents to understand the root causes, such as incomplete fixes or miscommunication with the user. Why it matters This flag directly measures resolution quality and customer satisfaction, highlighting cases where the initial fix was not effective. Where to get This is a calculated field, derived during data transformation by checking if an incident's event log contains a 'Reopened' activity or status transition. Examples truefalse
	Is SLA Breached IsSlaBreached	A boolean flag indicating if the incident resolution time exceeded the SLA target.
Description This is a simplified flag derived from the 'SLAStatus' attribute, where 'true' indicates the SLA was breached. This provides a clear, binary outcome for easy filtering and aggregation. This attribute is used to calculate the 'Critical Incident SLA Breach Rate' KPI. It allows for straightforward segmentation of all incidents into two groups, breached and not breached, to analyze the process characteristics that are most common among incidents that fail to meet service targets. Why it matters Provides a simple, binary outcome for SLA compliance, making it easy to calculate breach rates and analyze the common paths of non-compliant cases. Where to get Derived from the 'SLAStatus' attribute during data transformation. If 'SLAStatus' is 'Breached', this flag is set to true. Examples truefalse
	Reassignment Count ReassignmentCount	The total number of times an incident was transferred between different support groups.
Description This calculated attribute counts how many times the 'AssignedSupportGroup' field changed during an incident's lifecycle. A high number of reassignments, often called 'ticket ping-pong', indicates process inefficiencies, such as incorrect initial routing or knowledge gaps within support teams. This metric is the core of the 'Average Reassignments per Incident' KPI and the 'Incident Reassignment Analysis' dashboard. Tracking this count helps to identify opportunities to improve first-call resolution rates and streamline the routing process, ultimately reducing resolution time. Why it matters Quantifies process inefficiency and friction, highlighting incidents that suffer from being passed between teams, which delays resolution. Where to get Calculated during data transformation by counting the number of distinct values or changes in the 'AssignedSupportGroup' field over the lifecycle of each incident. Examples 0135
	Resolution Code ResolutionCode	A code or category indicating how the incident was ultimately resolved.
Description The Resolution Code captures the final outcome or the nature of the solution applied to an incident. This structured data is valuable for root cause analysis and understanding the types of solutions that are most frequently required. In analysis, this attribute can be compared with the initial 'IncidentCategory' to assess categorization accuracy. It also provides insights into common fixes, helping to build a knowledge base or identify areas where automation could be applied. Why it matters Provides structured data on incident outcomes, supporting root cause analysis and the improvement of knowledge management and automation. Where to get Consult Bmc Helix documentation. This field is typically found on the resolution tab or section of the incident form. Examples User Error - Training ProvidedSoftware Patch AppliedHardware ReplacedNo Fault Found
	Resolution Duration ResolutionDuration	The total time elapsed from when an incident was first reported to when it was resolved.
Description This metric measures the duration from the 'Incident Reported' activity to the 'Incident Resolved' activity. It is a key performance indicator for the efficiency of the entire incident management process. This calculated attribute is the basis for the 'Average Incident Resolution Time' KPI and the 'Incident Resolution Cycle Time' dashboard. Analyzing this duration across different incident categories, priorities, or teams helps identify systemic sources of delay and measure the impact of process improvement initiatives. Why it matters This is a primary measure of process efficiency and customer experience, directly reflecting how long it takes to restore service for users. Where to get Calculated during data transformation by finding the time difference between the timestamp of the 'Incident Resolved' activity and the 'Incident Reported' activity for each case. Examples 25920000086400000604800000

Required Recommended Optional

Incident Management Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and analysis.

6 Recommended 8 Optional

	Activity	Description
	Assigned to Support Group	This activity signifies the initial assignment of the incident to a specific support group for investigation and resolution. It represents the first handoff from the service desk to a technical team.
Why it matters This is a critical milestone for tracking first-touch resolution rates and initial response times. It helps identify delays in getting the incident to the right team. Where to get Captured by tracking the first population of the 'Assigned Group' field in the incident's audit history (HPD:HelpDesk_AuditLogSystem). Capture Inferred from the first recorded change to the 'Assigned Group' field in the audit logs. Event type inferred
	Incident Closed	The final activity in the lifecycle, where the incident record is formally closed and becomes a read-only historical record. This often occurs automatically after a set period in the 'Resolved' state.
Why it matters This activity marks the definitive end of the process. The time between 'Resolved' and 'Closed' can highlight delays in administrative processes or user confirmation windows. Where to get This is a distinct event inferred from the timestamp when the 'Status' field is updated to 'Closed'. This is tracked in the audit history. Capture Filter audit logs for the status change to 'Closed'. Event type inferred
	Incident Reported	Marks the creation of a new incident record in the system. This is the starting point of the incident lifecycle, typically triggered by a user submission via a portal, email, or a service desk agent manually creating the ticket.
Why it matters This activity is the primary start event for the process. Analyzing the time from this event to resolution is fundamental for measuring overall incident lifecycle duration and identifying upstream delays. Where to get This is an explicit creation event captured from the 'Submit Date' or 'Reported Date' timestamp on the HPD:Help Desk form. It is one of the most reliable and fundamental events in the system. Capture Captured from the creation timestamp of the incident record in the HPD:Help Desk table. Event type explicit
	Incident Resolved	Indicates that a resolution has been implemented and the service has been restored for the user. This is a key milestone, typically captured by a status change to 'Resolved'.
Why it matters This is a primary milestone for measuring the core resolution time. It signifies the end of the active work phase and often starts the clock for user confirmation or auto-closure procedures. Where to get This is a distinct event inferred from the timestamp when the 'Status' field is updated to 'Resolved'. This change is recorded in the audit history. Capture Filter audit logs for the status change to 'Resolved'. Event type inferred
	Resolution Identified	Represents the moment a support agent has found a solution and documented it in the incident record. The incident is now ready to be moved to a 'Resolved' state.
Why it matters This milestone marks the end of the technical investigation phase. The duration from this point to closure can reveal bottlenecks in communication, verification, and administrative processes. Where to get This is often inferred from the timestamp when the resolution details are entered and saved, just before the status is changed to 'Resolved'. Capture Use the timestamp of the last modification before the status changes to 'Resolved'. Event type inferred
	Workaround Implemented	Signifies that a temporary solution has been provided to the user, restoring service functionality while a permanent fix is being developed. This is often recorded by setting a specific flag or status.
Why it matters Tracking this helps measure the speed of service restoration, which is critical for user satisfaction. It separates temporary fixes from permanent resolutions in process analysis. Where to get This can be inferred from the timestamp when the 'Workaround' field in the incident resolution details is populated or when a specific 'Workaround Provided' status is used. Capture Use the timestamp of a status change to a 'Workaround' state or when resolution notes indicating a workaround are first saved. Event type inferred
	Incident Categorized	Represents the initial classification of the incident, including setting its category, type, and item. This activity is typically performed by a Level 1 service desk agent shortly after the incident is reported.
Why it matters Tracking this activity helps analyze the accuracy of initial classifications and its impact on routing and resolution. Changes to categorization later in the process indicate rework and potential knowledge gaps. Where to get Inferred from the first time the operational and product categorization fields ('OpCat', 'ProdCat') are populated in the incident's audit log (HPD:HelpDesk_AuditLogSystem). Capture Identify the first timestamp where categorization fields are set in the audit log. Event type inferred
	Incident Put On Hold	This activity occurs when the progress on an incident is paused, typically while waiting for information from the user or an external vendor. This is usually reflected by a status change to 'Pending'.
Why it matters This activity is crucial for accurately calculating resolution times. The time spent in a 'Pending' state should often be excluded from SLA calculations to fairly measure support team performance. Where to get Inferred from a change in the 'Status' field to a 'Pending' state. The audit log tracks the timestamp of this change. Capture Filter audit logs for status changes to 'Pending' or a similar on-hold status. Event type inferred
	Incident Reopened	Occurs when a previously resolved or closed incident is returned to an active state. This usually happens when the user reports that the issue has recurred.
Why it matters A high re-open rate indicates problems with the quality of resolutions. Tracking this rework loop is essential for identifying root causes of ineffective fixes and improving first-call resolution. Where to get Inferred from a status change from 'Resolved' or 'Closed' back to an active state like 'In Progress' or 'Assigned'. This transition is logged in the audit history. Capture Filter audit logs for a status change from a resolved/closed state to an open state. Event type inferred
	Investigation Started	Indicates that an assigned agent has started actively working on the incident. This is often represented by a status change from 'Assigned' to 'In Progress' or a similar state.
Why it matters Measuring the time between assignment and the start of investigation reveals queueing delays and helps assess agent responsiveness and workload capacity. Where to get This is inferred from a change in the 'Status' field from 'Assigned' to 'In Progress'. The timestamp of this status change is recorded in the audit log. Capture Filter audit logs for the first status change to 'In Progress' after an assignment. Event type inferred
	Pending Status Resumed	Marks the point where an incident that was on hold is reactivated. This happens when the required information is received, and is typically shown by the status moving from 'Pending' back to 'In Progress'.
Why it matters This event, paired with 'Incident Put On Hold', allows for the precise measurement of hold times. Analyzing long hold times can highlight communication issues with users or third parties. Where to get Inferred from a status change from 'Pending' to an active state like 'In Progress'. The timestamp is available in the audit log. Capture Filter audit logs for a status change from 'Pending' to 'In Progress' or 'Assigned'. Event type inferred
	SLA Breach Detected	A calculated event that occurs when the time taken to respond or resolve an incident exceeds the targets defined in its Service Level Agreement (SLA). This is not a direct system event.
Why it matters Identifying SLA breaches is crucial for compliance monitoring and prioritizing critical incidents. This helps pinpoint which stages of the process contribute most to breaches. Where to get This event is calculated by comparing the timestamp of the 'Incident Resolved' activity (or other SLA milestones) against the 'Reported Date' and the defined SLA target for that incident's priority. Capture Derive by comparing the resolution timestamp to the start timestamp plus the SLA duration. Event type calculated
	Transferred to Another Group	Represents the reassignment of an incident from one support group to another. This typically occurs when the initial group cannot resolve the issue and requires expertise from a different team.
Why it matters Frequent transfers, or 'ping-ponging', are a major source of delay and inefficiency. Analyzing these activities helps identify routing issues, skill gaps, and process bottlenecks. Where to get Inferred from a change in the value of the 'Assigned Group' field in the incident's audit history, subsequent to the initial assignment. Capture Each change to the 'Assigned Group' field in the audit log after the first assignment represents a transfer. Event type inferred
	User Confirmation Received	Represents the user acknowledging that the provided solution has fixed their issue. This is often an optional step and may be captured through a portal action or by an agent.
Why it matters Analyzing the rate and speed of user confirmations helps evaluate communication effectiveness and resolution quality. A low confirmation rate might lead to a higher re-open rate. Where to get This is difficult to capture directly and may need to be inferred. It could be a specific status like 'Resolved - Confirmed' or a note added to the incident work log. Capture Requires system analysis. Look for work log entries or status changes indicating user feedback. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Bmc Helix

Steps

Obtain Database Access: Secure read-only credentials for the Bmc Helix AR System's underlying SQL database (Oracle or MS SQL Server). You will need the server hostname, database name, username, and password.
Identify Key Tables: Connect to the database using a client like DBeaver or SQL Server Management Studio. Verify the exact names of the key tables. The query uses common names like HPD_Help_Desk, HPD_Help_Desk_AuditLogSystem, HPD_Assignment_Log, and SLM_Measurement, but your system's schema might have slight variations (e.g., a different schema prefix like ARADMIN).
Review the SQL Query: Examine the provided SQL query. It is structured to extract each of the 14 required activities as a separate event using a UNION ALL structure. Each SELECT block is tailored to capture a specific moment in the incident lifecycle.
Configure Query Placeholders: Modify the placeholders within the query. Set the date range by replacing '{start_date}' and '{end_date}' with your desired analysis period (e.g., '2023-01-01'). If necessary, filter for a specific company by replacing '[Your Company Name]' in the WHERE clause of the BaseIncidents CTE.
Execute the Query: Run the complete SQL query against the AR System database. The execution time may vary depending on the date range and the volume of incident data.
Inspect the Results: Briefly review the output to ensure it contains the expected columns (IncidentId, ActivityName, EventTimestamp, etc.) and that data appears to be populated correctly.
Export the Event Log: Export the query results to a CSV file. Ensure the file encoding is set to UTF-8 without BOM, which is the standard format for ProcessMind ingestion.
Prepare for Upload: Confirm the CSV file has the correct headers matching the attributes defined in the query. The file is now ready to be uploaded to ProcessMind as an event log.

Configuration

Database Credentials: A read-only database user is required to prevent any accidental modification of production data. Access must be granted to the AR System schema, which contains tables like HPD_Help_Desk.
Table and Schema Names: The provided query assumes a standard Bmc Helix schema. You may need to adjust table prefixes (e.g., dbo.HPD_Help_Desk) or table names based on your specific implementation.
Date Range: It is crucial to filter the query by a specific date range to manage the data volume and ensure efficient execution. A period of 3-6 months of data is typically recommended for an initial analysis. This is configured in the WHERE clause of the BaseIncidents common table expression.
Company Filter: For multi-tenant Bmc Helix environments, filtering by the 'Company' field is essential to isolate the data for a single business unit. This filter is also located in the BaseIncidents CTE.
Status Mappings: The query uses a CASE statement to map numerical status codes to human-readable names (e.g., 4 = 'Resolved'). Verify these mappings correspond to the status enum values configured in your system.
Performance Considerations: Direct database queries, especially those involving large audit and log tables, can be resource-intensive. It is highly recommended to run large extractions during off-peak business hours to minimize any potential impact on the live application.

a Sample Query sql

WITH BaseIncidents AS (
    SELECT 
        hpd.Incident_Number AS IncidentId,
        hpd.Submit_Date,
        hpd.Last_Resolved_Date,
        hpd.Closed_Date,
        hpd.Company,
        hpd.Description,
        hpd.Categorization_Tier_1, 
        hpd.Categorization_Tier_2, 
        hpd.Categorization_Tier_3,
        hpd.Priority,
        hpd.Urgency AS Severity, -- Using Urgency as Severity is a common practice
        hpd.Assigned_Group,
        hpd.Assignee,
        hpd.Status
    FROM HPD_Help_Desk hpd
    WHERE hpd.Submit_Date >= '{start_date}' AND hpd.Submit_Date < '{end_date}'
    -- Optional: Filter by a specific company if needed
    -- AND hpd.Company = '[Your Company Name]'
)
-- 1. Incident Reported
SELECT 
    bi.IncidentId AS IncidentId,
    'Incident Reported' AS ActivityName,
    DATEADD(s, bi.Submit_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'New' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
UNION ALL
-- 2. Incident Categorized (approximated at submission time)
SELECT 
    bi.IncidentId AS IncidentId,
    'Incident Categorized' AS ActivityName,
    DATEADD(s, bi.Submit_Date + 1, '1970-01-01') AS EventTimestamp, -- Adding 1 second to ensure order
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'New' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
UNION ALL
-- 3. Assigned to Support Group (first assignment)
SELECT
    log.Incident_Number,
    'Assigned to Support Group' AS ActivityName,
    DATEADD(s, log.Assignment_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Assigned' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    log.Assigned_Group AS AssignedSupportGroup,
    log.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Assignment_Log log
JOIN BaseIncidents bi ON log.Incident_Number = bi.IncidentId
WHERE log.Request_Type = 'Assignee'
AND log.Assignment_Date = (SELECT MIN(sub.Assignment_Date) FROM HPD_Assignment_Log sub WHERE sub.Incident_Number = log.Incident_Number AND sub.Request_Type = 'Assignee')
UNION ALL
-- 4. Investigation Started (Status moves to 'In Progress')
SELECT 
    bi.IncidentId,
    'Investigation Started' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'In Progress' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field = '2' -- 2 = In Progress
AND al.Log_Date = (SELECT MIN(sub.Log_Date) FROM HPD_Help_Desk_AuditLogSystem sub WHERE sub.Original_Request_ID = al.Original_Request_ID AND sub.Fields_Changed LIKE '%Status%' AND sub.New_Value_of_Field = '2')
UNION ALL
-- 5. Transferred to Another Group (subsequent assignments)
SELECT
    log.Incident_Number,
    'Transferred to Another Group' AS ActivityName,
    DATEADD(s, log.Assignment_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Assigned' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    log.Assigned_Group AS AssignedSupportGroup,
    log.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Assignment_Log log
JOIN BaseIncidents bi ON log.Incident_Number = bi.IncidentId
WHERE log.Request_Type = 'Assignee'
AND log.Assignment_Date > (SELECT MIN(sub.Assignment_Date) FROM HPD_Assignment_Log sub WHERE sub.Incident_Number = log.Incident_Number AND sub.Request_Type = 'Assignee')
UNION ALL
-- 6. Workaround Implemented (Using status reason as an indicator, may need adjustment)
SELECT 
    bi.IncidentId,
    'Workaround Implemented' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Pending' AS IncidentStatus, -- Often associated with a Pending status
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status_Reason%' AND al.New_Value_of_Field LIKE '%Workaround%'
UNION ALL
-- 7. Incident Put On Hold (Status moves to 'Pending')
SELECT 
    bi.IncidentId,
    'Incident Put On Hold' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Pending' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field = '3' -- 3 = Pending
UNION ALL
-- 8. Pending Status Resumed (Status moves from 'Pending' back to 'In Progress')
SELECT 
    bi.IncidentId,
    'Pending Status Resumed' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'In Progress' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field = '2' AND al.Old_Value_of_Field = '3' -- 2 = In Progress, 3 = Pending
UNION ALL
-- 9. Resolution Identified (Using Last_Resolved_Date)
SELECT 
    bi.IncidentId,
    'Resolution Identified' AS ActivityName,
    DATEADD(s, bi.Last_Resolved_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Resolved' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Last_Resolved_Date IS NOT NULL
UNION ALL
-- 10. Incident Resolved (Status moves to 'Resolved')
SELECT 
    bi.IncidentId,
    'Incident Resolved' AS ActivityName,
    DATEADD(s, bi.Last_Resolved_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Resolved' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Last_Resolved_Date IS NOT NULL
UNION ALL
-- 11. User Confirmation Received (Approximated as Closed Date)
SELECT 
    bi.IncidentId,
    'User Confirmation Received' AS ActivityName,
    DATEADD(s, bi.Closed_Date - 1, '1970-01-01') AS EventTimestamp, -- 1 second before closure
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Closed' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Closed_Date IS NOT NULL AND bi.Last_Resolved_Date IS NOT NULL AND bi.Status = 5
UNION ALL
-- 12. Incident Reopened
SELECT 
    bi.IncidentId,
    'Incident Reopened' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'In Progress' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field IN ('1', '2') AND al.Old_Value_of_Field IN ('4', '5') -- From Resolved/Closed to Assigned/In Progress
UNION ALL
-- 13. SLA Breach Detected
SELECT 
    bi.IncidentId,
    'SLA Breach Detected' AS ActivityName,
    DATEADD(s, slm.OverallStopTime, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    CASE bi.Status WHEN 4 THEN 'Resolved' WHEN 5 THEN 'Closed' ELSE 'In Progress' END AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    'Breached' AS SLAStatus
FROM SLM_Measurement slm
JOIN BaseIncidents bi ON slm.ApplicationUserFriendlyID = bi.IncidentId
WHERE slm.GoalStatus = 4 -- 4 = Missed
UNION ALL
-- 14. Incident Closed
SELECT 
    bi.IncidentId,
    'Incident Closed' AS ActivityName,
    DATEADD(s, bi.Closed_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Closed' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Closed_Date IS NOT NULL AND bi.Status = 5
ORDER BY IncidentId, EventTimestamp;

Steps

Prerequisites: Ensure you have Python 3.6+ installed on your system. You will also need credentials for a BMC Helix user account with at least read access to the HPD:Help Desk and HPD:HelpDesk_AuditLogSystem forms via the REST API.
Install Python Libraries: Open your terminal or command prompt and install the requests and pandas libraries, which are necessary for making API calls and handling data. Execute the command: pip install requests pandas.
Configure the Script: Save the provided Python code to a file named extract_incidents.py. Open this file in an editor and update the placeholder variables at the top: HELIX_URL, HELIX_USER, HELIX_PASSWORD, START_DATE, and END_DATE with your specific environment details and desired date range.
Authentication: The script first authenticates with the BMC Helix API. It sends a POST request to the /api/jwt/login endpoint with the provided credentials to obtain a JSON Web Token (JWT). This token is then included in the header of all subsequent data requests.
Fetch Incident Data: The script queries the HPD:Help Desk form to retrieve a list of all incidents created within the specified date range. This initial query gathers the main attributes for each incident and creates the 'Incident Reported' event, which is the starting point for every case.
Fetch Audit Log Data: For each incident retrieved in the previous step, the script performs a second API call to the HPD:HelpDesk_AuditLogSystem form. This form contains the detailed change history for each incident, such as status changes, group reassignments, and priority updates.
Map Audit Events to Activities: The script iterates through the audit log entries for each incident. It uses a series of logical checks to map raw field changes to the required business activities. For example, a change in the Status field from 'Assigned' to 'In Progress' is translated into an 'Investigation Started' activity.
Handle Special and Calculated Activities: The script includes specific logic to derive activities that are not simple field changes. 'SLA Breach Detected' is created by comparing the Last Resolved Date to the Target Date. 'Incident Reopened' is generated when the status moves from 'Resolved' or 'Closed' back to an active state.
Structure the Event Log: As the script processes each incident and its audit history, it constructs a list of events. Each event is a dictionary containing all required and recommended attributes (IncidentId, ActivityName, EventTimestamp, etc.).
Execute the Extraction: Run the script from your terminal using the command: python extract_incidents.py. The script will print progress updates to the console as it fetches and processes the data.
Export to CSV: Once the script completes, it will save the final event log as a CSV file named bmc_helix_incident_event_log.csv in the same directory. This file is formatted for direct upload into a process mining tool.

Configuration

HELIX_URL: The base URL for your BMC Helix REST API. For example, https://[your-tenant].onbmc.com.
HELIX_USER / HELIX_PASSWORD: Credentials for a service account or user with API access permissions for the incident management forms.
START_DATE / END_DATE: The date range for the extraction, formatted as 'YYYY-MM-DD'. It is recommended to start with a smaller range, such as 3-6 months, to manage the extraction volume and duration.
INCIDENT_QUERY_FIELDS: A list of fields to retrieve from the main HPD:Help Desk form. This can be customized to include additional attributes relevant to your analysis.
PAGE_SIZE: This variable controls the number of incidents fetched per API call to avoid timeouts and manage memory usage. A value between 500 and 1000 is typically effective.
q (Query Qualification): The script constructs a query qualification string to filter incidents by their Submit Date. You can extend this query to add other filters, such as AND 'Company' = "[Your Company Name]" to limit the scope of the extraction.

a Sample Query python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
HELIX_URL = class="hl-string">"https://[your-tenant].onbmc.com"
HELIX_USER = class="hl-string">"[YOUR_USERNAME]"
HELIX_PASSWORD = class="hl-string">"[YOUR_PASSWORD]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"[START_DATE]" class=class="hl-string">"hl-comment"># Example: class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"[END_DATE]"     class=class="hl-string">"hl-comment"># Example: class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># Fields to retrieve from the main Incident form
INCIDENT_QUERY_FIELDS = (
    class="hl-string">"'Incident Number', 'Submitter', 'Submit Date', 'Status', 'Status_Reason', "
    class="hl-string">"'Priority', 'Urgency', 'Impact', 'Service Type', 'Assigned Group', 'Assignee', "
    class="hl-string">"'Last Resolved Date', 'Closed Date', 'Company', 'Description', 'Target Date'"
)

PAGE_SIZE = 1000

class=class="hl-string">"hl-comment"># --- Main Script --- 

def get_jwt_token(session, base_url, user, password):
    class="hl-string">"""Authenticates with the API and returns a JWT token."""
    login_url = fclass="hl-string">"{base_url}/api/jwt/login"
    auth_data = {class="hl-string">"username": user, class="hl-string">"password": password}
    try:
        response = session.post(login_url, data=auth_data, headers={class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'})
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error during authentication: {e}")
        return None

def fetch_paginated_data(session, url, params):
    class="hl-string">"""Fetches all pages of data from a given endpoint."""
    all_entries = []
    start_index = 0
    while True:
        params[class="hl-string">'offset'] = start_index
        response = session.get(url, params=params)
        response.raise_for_status()
        data = response.json()
        entries = data.get(class="hl-string">'entries', [])
        all_entries.extend(entries)
        if not entries or len(entries) < params.get(class="hl-string">'limit', PAGE_SIZE):
            break
        start_index += len(entries)
    return all_entries

def map_audit_log_to_activity(log_entry, prev_values):
    class="hl-string">"""Maps audit log changes to specific activity names."""
    fields_changed = log_entry[class="hl-string">'values'].get(class="hl-string">'Fields Changed', class="hl-string">'')
    log_date = datetime.fromisoformat(log_entry[class="hl-string">'values'][class="hl-string">'Log Date'].replace(class="hl-string">'Z', class="hl-string">'+00:00')).isoformat()
    
    class=class="hl-string">"hl-comment"># Status changes
    if class="hl-string">'Status' in fields_changed:
        new_status = log_entry[class="hl-string">'values'].get(class="hl-string">'Status', class="hl-string">'')
        prev_status = prev_values.get(class="hl-string">'Status', class="hl-string">'')
        if prev_status == class="hl-string">'Assigned' and new_status == class="hl-string">'In Progress': return {class="hl-string">'ActivityName': class="hl-string">'Investigation Started', class="hl-string">'Timestamp': log_date}
        if prev_status == class="hl-string">'Pending' and new_status == class="hl-string">'In Progress': return {class="hl-string">'ActivityName': class="hl-string">'Pending Status Resumed', class="hl-string">'Timestamp': log_date}
        if new_status == class="hl-string">'Pending': return {class="hl-string">'ActivityName': class="hl-string">'Incident Put On Hold', class="hl-string">'Timestamp': log_date}
        if new_status == class="hl-string">'Resolved': return {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'Timestamp': log_date}
        if new_status == class="hl-string">'Closed': return {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'Timestamp': log_date}
        if prev_status in [class="hl-string">'Resolved', class="hl-string">'Closed'] and new_status in [class="hl-string">'In Progress', class="hl-string">'Assigned']: return {class="hl-string">'ActivityName': class="hl-string">'Incident Reopened', class="hl-string">'Timestamp': log_date}
    
    class=class="hl-string">"hl-comment"># Assignment changes
    if class="hl-string">'Assigned Group' in fields_changed:
        new_group = log_entry[class="hl-string">'values'].get(class="hl-string">'Assigned Group')
        if prev_values.get(class="hl-string">'Assigned Group') is None and new_group is not None: return {class="hl-string">'ActivityName': class="hl-string">'Assigned to Support Group', class="hl-string">'Timestamp': log_date}
        if prev_values.get(class="hl-string">'Assigned Group') is not None and new_group is not None and prev_values.get(class="hl-string">'Assigned Group') != new_group:
            return {class="hl-string">'ActivityName': class="hl-string">'Transferred to Another Group', class="hl-string">'Timestamp': log_date}

    class=class="hl-string">"hl-comment"># Other specific activities
    if class="hl-string">'Service Type' in fields_changed or class="hl-string">'Categorization Tier 1' in fields_changed: return {class="hl-string">'ActivityName': class="hl-string">'Incident Categorized', class="hl-string">'Timestamp': log_date}
    if class="hl-string">'Status_Reason' in fields_changed and log_entry[class="hl-string">'values'].get(class="hl-string">'Status_Reason') == class="hl-string">'Solution Provided': return {class="hl-string">'ActivityName': class="hl-string">'Resolution Identified', class="hl-string">'Timestamp': log_date}
    if class="hl-string">'Status_Reason' in fields_changed and log_entry[class="hl-string">'values'].get(class="hl-string">'Status_Reason') == class="hl-string">'Customer Confirmation': return {class="hl-string">'ActivityName': class="hl-string">'User Confirmation Received', class="hl-string">'Timestamp': log_date}
    if class="hl-string">'z1D_WorkInfoType' in fields_changed and log_entry[class="hl-string">'values'].get(class="hl-string">'z1D_WorkInfoType') == class="hl-string">'Workaround': return {class="hl-string">'ActivityName': class="hl-string">'Workaround Implemented', class="hl-string">'Timestamp': log_date}

    return None

if __name__ == class="hl-string">"__main__":
    event_log = []
    session = requests.Session()

    class=class="hl-string">"hl-comment"># 1. Authenticate
    print(class="hl-string">"Authenticating with BMC Helix...")
    jwt_token = get_jwt_token(session, HELIX_URL, HELIX_USER, HELIX_PASSWORD)
    if not jwt_token:
        exit()
    session.headers.update({class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {jwt_token}'})

    class=class="hl-string">"hl-comment"># 2. Fetch Incidents
    print(fclass="hl-string">"Fetching incidents from {START_DATE} to {END_DATE}...")
    incident_url = fclass="hl-string">"{HELIX_URL}/api/arsys/v1/entry/HPD:Help Desk"
    qualification = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    params = {class="hl-string">'q': qualification, class="hl-string">'fields': fclass="hl-string">'values({INCIDENT_QUERY_FIELDS})', class="hl-string">'limit': PAGE_SIZE}

    try:
        incidents = fetch_paginated_data(session, incident_url, params)
        print(fclass="hl-string">"Found {len(incidents)} incidents.")

        class=class="hl-string">"hl-comment"># 3. Process each incident
        for i, incident in enumerate(incidents):
            vals = incident[class="hl-string">'values']
            incident_id = vals.get(class="hl-string">'Incident Number')
            if not incident_id:
                continue
            
            print(fclass="hl-string">"Processing Incident {i+1}/{len(incidents)}: {incident_id}")

            base_attributes = {
                class="hl-string">'IncidentId': incident_id,
                class="hl-string">'SourceSystem': class="hl-string">'Bmc Helix',
                class="hl-string">'LastDataUpdate': datetime.now().isoformat(),
                class="hl-string">'Priority': vals.get(class="hl-string">'Priority'),
                class="hl-string">'Severity': vals.get(class="hl-string">'Impact'),
                class="hl-string">'IncidentCategory': vals.get(class="hl-string">'Service Type')
            }
            
            class=class="hl-string">"hl-comment"># Activity: Incident Reported
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Incident Reported',
                class="hl-string">'EventTimestamp': datetime.fromisoformat(vals[class="hl-string">'Submit Date'].replace(class="hl-string">'Z', class="hl-string">'+00:00')).isoformat(),
                class="hl-string">'IncidentStatus': class="hl-string">'New',
                class="hl-string">'AssignedSupportGroup': vals.get(class="hl-string">'Assigned Group'),
                class="hl-string">'AssignedAgent': vals.get(class="hl-string">'Assignee'),
                class="hl-string">'SLAStatus': class="hl-string">'In Progress'
            })

            class=class="hl-string">"hl-comment"># 4. Fetch Audit Log
            audit_url = fclass="hl-string">"{HELIX_URL}/api/arsys/v1/entry/HPD:HelpDesk_AuditLogSystem"
            audit_params = {
                class="hl-string">'q': fclass="hl-string">"'Incident Number' = \"{incident_id}\class="hl-string">"",
                class="hl-string">'fields': class="hl-string">"values(Log Date, Fields Changed, Status, Assigned Group, Status_Reason, z1D_WorkInfoType, Service Type, Categorization Tier 1)",
                class="hl-string">'sort': class="hl-string">'Log Date.asc'
            }
            audit_logs = fetch_paginated_data(session, audit_url, audit_params)

            class=class="hl-string">"hl-comment"># 5. Map audit log to activities
            current_values = {class="hl-string">'Status': class="hl-string">'New', class="hl-string">'Assigned Group': None}
            for log in audit_logs:
                activity_info = map_audit_log_to_activity(log, current_values)
                if activity_info:
                    event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': activity_info[class="hl-string">'ActivityName'],
                        class="hl-string">'EventTimestamp': activity_info[class="hl-string">'Timestamp'],
                        class="hl-string">'IncidentStatus': log[class="hl-string">'values'].get(class="hl-string">'Status', current_values[class="hl-string">'Status']),
                        class="hl-string">'AssignedSupportGroup': log[class="hl-string">'values'].get(class="hl-string">'Assigned Group', current_values.get(class="hl-string">'Assigned Group')),
                        class="hl-string">'AssignedAgent': None, class=class="hl-string">"hl-comment"># Assignee not typically in audit log
                        class="hl-string">'SLAStatus': class="hl-string">'In Progress' class=class="hl-string">"hl-comment"># Simplified
                    })
                class=class="hl-string">"hl-comment"># Update current values for next iteration
                current_values[class="hl-string">'Status'] = log[class="hl-string">'values'].get(class="hl-string">'Status', current_values[class="hl-string">'Status'])
                current_values[class="hl-string">'Assigned Group'] = log[class="hl-string">'values'].get(class="hl-string">'Assigned Group', current_values.get(class="hl-string">'Assigned Group'))

            class=class="hl-string">"hl-comment"># Activity: SLA Breach Detected (Calculated)
            resolved_date_str = vals.get(class="hl-string">'Last Resolved Date')
            target_date_str = vals.get(class="hl-string">'Target Date')
            if resolved_date_str and target_date_str:
                resolved_date = datetime.fromisoformat(resolved_date_str.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                target_date = datetime.fromisoformat(target_date_str.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                if resolved_date > target_date:
                     event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Breach Detected',
                        class="hl-string">'EventTimestamp': target_date.isoformat(),
                        class="hl-string">'IncidentStatus': vals.get(class="hl-string">'Status'),
                        class="hl-string">'AssignedSupportGroup': vals.get(class="hl-string">'Assigned Group'),
                        class="hl-string">'AssignedAgent': vals.get(class="hl-string">'Assignee'),
                        class="hl-string">'SLAStatus': class="hl-string">'Breached'
                    })

    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"An API error occurred: {e}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

    class=class="hl-string">"hl-comment"># 6. Export to CSV
    if event_log:
        print(class="hl-string">"Exporting event log to CSV...")
        df = pd.DataFrame(event_log)
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(class="hl-string">'bmc_helix_incident_event_log.csv', index=False)
        print(class="hl-string">"Extraction complete. File 'bmc_helix_incident_event_log.csv' created.")
    else:
        print(class="hl-string">"No events were generated.")

Data Template: Incident Management

Your Incident Management Data Template

Incident Management Attributes

Incident Management Activities

Extraction Guides

Direct SQL Query on the Underlying AR System Database

Steps

Configuration

a Sample Query sql

Python Script Extraction via BMC Helix REST API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize BMC Helix Incident Management Today!