> Continuous Process Improvement > Problem Management > BMC Helix ITSM > Data Template

Your Problem Management Data Template

BMC Helix ITSM

Problem Management Attributes (19) Problem Management Activities (13) Extraction Guides (3)

Your Problem Management Data Template

This template provides a comprehensive structure for analyzing your root cause investigation workflows within BMC Helix ITSM. It outlines the essential attributes and process activities needed to build a detailed event log, alongside practical extraction guidance. By following this guide, you can identify hidden bottlenecks and streamline your path to permanent incident resolution.

Essential data fields for root cause analysis
Standardized process milestones for tracking
Specific extraction guidance for BMC Helix ITSM

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

Download Template

Problem Management Attributes

This table contains the recommended data fields required to populate your event log for a thorough analysis of your problem management lifecycle.

5 Required 9 Recommended 5 Optional

	Name	Description
	Activity Activity	The specific task or status change event that occurred.
Description This attribute represents the specific step performed in the problem management lifecycle, such as 'Problem Record Logged', 'Root Cause Identified', or 'Solution Database Updated'. In BMC Helix, these are often derived from the Status History, Audit Logs, or specific transaction timestamps within the Problem Investigation module. This attribute is the core of process discovery. By analyzing the sequence of these activities, the process mining tool constructs the process map, revealing the actual flow of work compared to the designed process. It highlights loops, rework, and deviations from the standard operating procedure. Accurate activity names are crucial for understanding what actually happened during the lifecycle. This data allows for the measurement of transition times between specific steps, such as the time taken between identifying a root cause and initiating a change request. Why it matters It defines the nodes in the process map and allows for the visualization of the workflow. Where to get Derived from PBM:Problem Investigation status history or PBM:AuditLogSystem Examples Problem Record LoggedAssigned to Support GroupInvestigation CommencedRoot Cause Identified
	Event Time EventTime	The timestamp when the specific activity occurred.
Description This attribute records the exact date and time when an activity took place. In BMC Helix ITSM, this corresponds to fields like 'Submit Date', 'Last Modified Date', or specific timestamps recorded in the history tables corresponding to status changes. In analysis, this attribute is used to sequence events chronologically and calculate durations. It enables the measurement of cycle times between any two points in the process, such as the 'Investigation Cycle Time' or the 'Workaround Publication Lead Time'. Precise timestamps are vital for identifying bottlenecks. By calculating the time difference between consecutive events, analysts can pinpoint exactly where delays are occurring, whether it is during the initial assignment or the final review phase. Why it matters It enables the calculation of all duration-based KPIs and the sequencing of events. Where to get History tables or audit logs associated with PBM:Problem Investigation Examples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
	Problem Record ProblemRecord	The unique identifier for the problem investigation case.
Description This attribute serves as the central case identifier for the problem management process. In BMC Helix ITSM, this is typically the 'Problem ID' field (e.g., PBI00000012345) found on the PBM:Problem Investigation form. It links all related activities, from the initial logging of the problem to the final closure and post-implementation review. In process mining analysis, this attribute is used to group individual events into a single process instance. It allows analysts to visualize the end-to-end journey of a specific problem investigation. Without this identifier, it would be impossible to correlate the sequence of actions taken by different support groups and coordinators. This field functions as the primary key for the event log and is essential for all case-level aggregations, such as calculating the total cycle time per problem or counting the number of problems per priority level. Why it matters It is the fundamental key required to construct the process view and track the lifecycle of specific issues. Where to get PBM:Problem Investigation form, field 'Problem ID' Examples PBI00000004512PBI00000004513PBI00000004514
	Last Data Update LastDataUpdate	The timestamp when the data was extracted or last refreshed.
Description This attribute indicates when the data was last loaded into the process mining application. It ensures that analysts are aware of the currency of the data they are viewing. It is usually generated by the extraction script or the data pipeline tool. In analysis, this helps prevent decisions based on stale data. For example, if a manager is looking at 'Open Problem Records', knowing that the data was updated an hour ago versus a week ago significantly changes the interpretation of the current workload. It is also used for incremental data loads. By tracking the last update time, the ETL process can fetch only records that have changed since the previous extraction, optimizing performance and reducing system load. Why it matters It ensures data freshness and assists in incremental data loading strategies. Where to get System time at moment of extraction Examples 2023-11-01T00:00:00Z2023-11-01T12:00:00Z
	Source System SourceSystem	The system where the data originated.
Description This attribute identifies the software system from which the process data was extracted, in this case, 'BMC Helix ITSM'. It is particularly important in multi-system environments where process mining might aggregate data from various ITSM, development, or external vendor tools. In analysis, this field serves as a metadata tag that validates the origin of the record. If the process mining view combines data from BMC Helix for problem management and a separate system for software development (e.g., Jira), this attribute helps segment the analysis by the tool of origin. It also aids in technical troubleshooting. If data quality issues arise, knowing the source system allows data engineers to trace the issue back to the specific extraction routine or source database. Why it matters It provides traceability and context, especially in multi-system process views. Where to get Hardcoded during the extraction process Examples BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
	Investigation Driver InvestigationDriver	The reason why the problem investigation was initiated.
Description This attribute classifies the trigger for the problem record, such as 'Incident Volume', 'Major Incident', 'Vendor Notification', or 'Proactive Trend Analysis'. In BMC Helix, this is the 'Investigation Driver' field. This attribute supports the 'Proactive Identification Trends' dashboard. It allows the organization to measure the shift from reactive firefighting (responding to incidents) to proactive problem management (identifying risks before they manifest). Analyzing process flows by 'Investigation Driver' can reveal different behaviors. For instance, 'Proactive' problems might sit in the queue longer because they are not causing immediate outages, whereas 'Major Incident' driven problems are rushed through the process. Why it matters It distinguishes between reactive and proactive work, a key maturity indicator. Where to get PBM:Problem Investigation form, field 'Investigation Driver' Examples ReactiveProactiveRecurring Incidents
	Is SLA Breached IsSLABreached	A flag indicating if the problem resolution exceeded the allowed time.
Description This boolean attribute indicates whether the problem record breached its service level agreement. It is calculated by comparing the 'Resolution Verified' timestamp against the 'SLA Due Date' or extracted directly from the SLM status. This attribute is critical for the 'SLA Compliance and Breach Trends' dashboard. It allows for a simple binary segmentation of the process: compliant vs. non-compliant. This makes it easy to isolate the characteristics of failed processes (e.g., 'Do breached cases always involve Support Group X?'). It serves as a primary filter for root cause analysis of process failures. Analysts can filter for 'IsSLABreached = True' and then examine the process map to see where the time was lost (e.g., long wait times for vendor approval). Why it matters It simplifies compliance reporting and failure analysis. Where to get SLM:Measurement form or calculated Examples truefalse
	Priority Priority	The calculated priority of the problem based on impact and urgency.
Description This attribute indicates the priority level of the problem record (e.g., Critical, High, Medium, Low). In BMC Helix, this is usually a calculated field derived from Impact and Urgency selections. In analysis, this is used for the 'Throughput and Priority Volume' dashboard. It allows organizations to verify if resources are correctly aligned with business needs. For instance, 'Critical' problems should theoretically have faster initial assignment times and shorter overall cycle times compared to 'Low' priority ones. Filtering by priority helps focus improvement efforts. A bottleneck in a 'Low' priority process might be acceptable, but the same delay in a 'Critical' process represents a significant risk to business continuity and SLA compliance. Why it matters It segments analysis by business criticality and supports SLA analysis. Where to get PBM:Problem Investigation form, field 'Priority' Examples CriticalHighMediumLow
	Problem Coordinator ProblemCoordinator	The individual user assigned to coordinate the investigation.
Description This attribute names the specific person responsible for the problem record. In BMC Helix ITSM, this is the 'Problem Coordinator' field. This person owns the lifecycle of the problem even if tasks are delegated to others. This attribute supports the 'Support Group Workload Distribution' dashboard. It helps managers identify if specific individuals are overloaded with investigations while others have capacity. It also allows for performance analysis at the individual level, helping to identify training needs or high performers. In process mining, this field acts as a resource attribute. It helps visualize how work flows between individuals and can highlight single points of failure where a process relies too heavily on one specific expert. Why it matters It allows for resource analysis and workload balancing at the individual level. Where to get PBM:Problem Investigation form, field 'Problem Coordinator' Examples John DoeJane SmithSystem Admin
	Related Incident Count RelatedIncidentCount	The number of incidents linked to this problem record.
Description This attribute quantifies the impact of the problem by counting the number of incidents associated with it. In BMC Helix, this is usually a count of records in the HPD:Help Desk form that are related to the PBM record. This attribute drives the 'Incident Linkage Density' KPI. A high count indicates a high-impact problem that is generating significant noise for the service desk. Correlating this with 'Priority' ensures that high-volume problems are actually being treated as critical. It also helps prioritize the backlog. A problem record with 500 linked incidents should likely be prioritized over a 'Critical' problem with only 1 linked incident, as resolving the former will free up more service desk capacity. Why it matters It quantifies the operational impact and user pain associated with the problem. Where to get Calculated by counting related rows in HPD:Associations or HPD:Help Desk Examples 15120
	Root Cause Category RootCauseCategory	The classification of the underlying cause of the problem.
Description This attribute contains the category selected when the root cause is identified (e.g., 'Software Error', 'Hardware Failure', 'Process Gap'). In BMC Helix, this is typically selected from the 'Root Cause' or 'Generic Categorization' menus. This attribute is essential for the 'Fix Effectiveness and Quality' view. It allows the organization to correlate specific types of root causes with rework rates or long investigation times. For example, it might reveal that 'Software Error' problems consistently take twice as long to resolve as 'Hardware Failure' problems. It is also used to calculate the 'Root Cause Categorization Rate'. A high percentage of 'Unknown' or 'Other' values in this field suggests a need for better technical training or more granular categorization options. Why it matters It enables trend analysis of systemic issues and supports proactive problem management. Where to get PBM:Problem Investigation form, 'Root Cause' or categorization tab fields Examples Software ModuleNetwork InfrastructureHuman Error
	Service CI ServiceCI	The primary business service or configuration item affected.
Description This attribute identifies the Service Configuration Item (CI) related to the problem, such as 'Email Service', 'SAP ERP', or 'Wi-Fi Network'. In BMC Helix, this is often the 'Service+' field or the primary CI relationship. In analysis, this allows for the segmentation of problem records by product or service. It helps IT leadership understand which services are most fragile and generating the most problem investigations. This feeds into the 'Throughput and Priority Volume' dashboard by adding a product dimension. Correlating this attribute with 'Investigation Cycle Time' can show if certain complex services (like a core banking system) inherently require longer investigation periods compared to commodity services (like printing). Why it matters It links the process performance to specific business products or services. Where to get PBM:Problem Investigation form, field 'ServiceCI' or 'CI Name' Examples Email ServicePayroll SystemCorporate VPN
	SLA Due Date SLADueDate	The target date and time by which the problem must be resolved.
Description This attribute holds the deadline for the problem resolution based on the service level agreement. In BMC Helix, this is often the 'Target Resolution Date' or a calculated SLA milestone timestamp. This attribute is the baseline for the 'SLA Compliance and Breach Trends' dashboard. By comparing this timestamp with the 'Resolution Verified' activity timestamp, the system calculates whether the SLA was met or breached. Visualizing this date allows analysts to see how close the team cuts it. Are they resolving problems days in advance, or are they consistently finishing just minutes before the breach? This insight drives capacity planning. Why it matters It is the reference point for calculating all compliance and timeliness metrics. Where to get PBM:Problem Investigation form, 'Target Resolution Date' field Examples 2023-12-01T17:00:00Z2023-12-02T09:00:00Z
	Support Group SupportGroup	The technical team currently assigned to the problem investigation.
Description This attribute reflects the specific support group (e.g., 'Server Admin', 'Database Support') responsible for the problem record at the time of the event. In BMC Helix, this is the 'Assigned Group' field. This attribute is critical for the 'Support Group Workload Distribution' and 'Support Group Reassignment Analysis' dashboards. It allows analysts to slice the process map by team, revealing which groups are handling the most volume and which are bottlenecks in the investigation process. Analyzing handovers between support groups helps identify 'ping-pong' behavior, where a ticket bounces between teams without resolution. This often points to unclear responsibilities or inadequate knowledge management within the organization. Why it matters It enables organizational analysis and bottleneck detection at the team level. Where to get PBM:Problem Investigation form, field 'Assigned Group' Examples Service Desk Level 1Back Office SupportNetwork Administration
	Investigation Cycle Time InvestigationCycleTime	The duration from investigation start to root cause identification.
Description This is a calculated duration attribute measuring the time between the 'Investigation Commenced' activity and the 'Root Cause Identified' activity. It represents the core value-add time of the problem management process. This metric feeds the 'Root Cause Investigation Cycle Time' dashboard. It helps managers understand the technical complexity of issues and the efficiency of the investigation teams. Anomalies here (e.g., extremely short times) might indicate guessing, while extremely long times indicate stalled investigations. By comparing this metric across 'Support Groups' and 'Priorities', the organization can identify which teams need better tools, training, or vendor support to diagnose issues faster. Why it matters It is the primary efficiency metric for the technical investigation phase. Where to get Calculated from activity timestamps Examples 4500000120000
	Reassignment Count ReassignmentCount	The total number of times the support group was changed.
Description This attribute counts the number of times the 'Assigned to Support Group' activity occurs for a single case. It is a direct measure of process friction and routing efficiency. This attribute populates the 'Support Group Reassignment Analysis' chart. High values (ping-ponging) indicate that the initial triage is failing or that there is no clear ownership for complex issues. It is a leading indicator of increased cycle time. Managers use this to identify training opportunities. If the Service Desk consistently reassigns 'Database' problems to 'Network' first, and then 'Network' sends them to 'Database', the Reassignment Count will spike, highlighting the need for better initial diagnosis scripts. Why it matters It identifies waste, friction, and lack of ownership in the process. Where to get Calculated from activity history Examples 015
	Region Region	The geographical region associated with the problem.
Description This attribute specifies the geographic location (e.g., 'North America', 'EMEA') where the problem originated or is being managed. In BMC Helix, this is often found in the 'Region' or 'Site' fields associated with the requester or the affected asset. In analysis, this supports geographical segmentation. It helps identify if specific regions are experiencing higher problem volumes or slower resolution times. This can highlight disparities in support staffing or infrastructure quality across different locations. It is valuable for global organizations to ensure consistent service delivery. If the 'Investigation Cycle Time' in 'APAC' is double that of 'NAM', it prompts an investigation into resource allocation or process adherence in that region. Why it matters It enables geographical comparison of process performance. Where to get PBM:Problem Investigation form, 'Region' field Examples AmericasEMEAAPAC
	Related Change Request ID RelatedChangeRequestId	The identifier of the change request initiated to fix the problem.
Description This attribute contains the ID of the Change Request (e.g., CRQ0000...) linked to the problem record. It represents the transition from investigation to implementation of a permanent fix. This attribute is necessary for the 'Root Cause to Change Lead Time' KPI. It allows the process mining tool to measure the delay between finding the root cause and starting the change process. This is a common handover point where momentum is lost. It also helps verify the 'process completeness'. A problem record closed with a status of 'Completed' but without a related change request (or a workaround) might indicate a process violation where the root cause was found but never actually fixed. Why it matters It links the problem management process to the change management process. Where to get PBM:Investigation Associations or Relationship tab Examples CRQ00000021345CRQ00000021346
	Workaround Status WorkaroundStatus	Indicates if a valid workaround has been identified and published.
Description This attribute tracks the state of the temporary solution (Workaround). It might be a simple boolean (Has Workaround) or a status string. In BMC Helix, this is often derived from the presence of text in the 'Workaround' field or a specific status flag. This attribute is key to the 'Workaround Publication Performance' dashboard. It answers how effectively the team mitigates impact while researching the root cause. A process view filtered by 'No Workaround' highlights cases where the business is suffering full impact during the investigation. It also supports quality audits. Closing a problem record without a permanent fix (Change Request) AND without a workaround is generally a process failure that needs review. Why it matters It measures the effectiveness of impact mitigation during the investigation. Where to get PBM:Problem Investigation form, 'Workaround' field content check Examples ActiveNoneRetired

Required Recommended Optional

Problem Management Activities

These are the fundamental process steps and status changes you should track to achieve full visibility into your investigation and resolution phases.

9 Recommended 4 Optional

	Activity	Description
	Assigned to Support Group	The assignment of the problem record to a specific technical team. Captured by monitoring changes to the 'Assigned Group' field.
Why it matters Essential for measuring handoffs, ping-pong effects, and the 'Mean Time to Initial Assignment' KPI. Where to get PBM:Problem Investigation form, 'Assigned Group' field history or audit log. Capture Compare 'Assigned Group' field before and after update Event type inferred
	Change Request Initiated	The linking of an Infrastructure Change Request to the Problem Investigation. This signals the start of the implementation phase.
Why it matters Critical for the 'Root Cause to Change Lead Time' KPI and identifying silos between Problem and Change processes. Where to get PBM:Investigation_Associations table or 'Infrastructure Change ID' field population. Capture Logged when association created in PBM:Investigation_Associations Event type explicit
	Investigation Commenced	The transition of the problem record into an active analysis phase. This is inferred when the Status field changes to 'Under Investigation'.
Why it matters Marks the beginning of the actual work phase, supporting the 'Investigation Cycle Time' KPI. Where to get PBM:Problem Investigation form, 'Status' field = 'Under Investigation'. Capture Compare status field for transition to Under Investigation Event type inferred
	Problem Record Cancelled	The termination of a problem record before resolution. Captured when status becomes 'Cancelled' or 'Rejected'.
Why it matters Identify wasted effort or valid duplicates. Represents an alternative end point. Where to get PBM:Problem Investigation form, 'Status' field = 'Cancelled' or 'Rejected'. Capture Compare status field for transition to Cancelled Event type inferred
	Problem Record Closed	The final administrative closure of the problem record. This event terminates the process instance.
Why it matters The standard end event. Necessary for full cycle time analysis and 'Incident Linkage Density' calculation. Where to get PBM:Problem Investigation form, 'Status' field = 'Closed'. Capture Compare status field for transition to Closed Event type inferred
	Problem Record Logged	The initial creation of a Problem Investigation record in the system. This event is explicitly captured when a new entry is saved in the PBM:Problem Investigation form.
Why it matters Marks the start of the process instance. Critical for calculating overall cycle times and initial response metrics. Where to get PBM:Problem Investigation form, 'Submit Date' timestamp or 'Status' = 'Draft' creation log. Capture Logged when PBM:Problem Investigation record is created Event type explicit
	Resolution Verified	The point where the permanent fix is confirmed successful. Inferred from Status changing to 'Solution Implemented' or 'Completed'.
Why it matters Used for 'Problem SLA Adherence Rate'. Confirms the technical work is finished. Where to get PBM:Problem Investigation form, 'Status' field = 'Solution Implemented' or 'Completed'. Capture Compare status field for transition to Solution Implemented Event type inferred
	Root Cause Identified	The moment the problem record transitions to a state indicating the cause is known. Inferred when the Status changes to 'Root Cause Identified'.
Why it matters A critical milestone for the 'Root Cause Investigation Cycle Time' dashboard. Signals the shift from analysis to solutioning. Where to get PBM:Problem Investigation form, 'Status' field = 'Root Cause Identified'. Capture Compare status field for transition to Root Cause Identified Event type inferred
	Workaround Defined	The entry or update of text in the Workaround field of the problem record. This event indicates a temporary solution has been documented.
Why it matters Supports the 'Workaround Publication Lead Time' KPI. Indicates incident impact mitigation. Where to get PBM:Problem Investigation form, changes to the 'Workaround' text field. Capture Compare 'Workaround' field content for non-null updates Event type inferred
	Coordinator Reassigned	A change in the individual Problem Coordinator within a support group. Captured by monitoring the 'Problem Coordinator' field.
Why it matters Helps analyze workload distribution and individual resource bottlenecks. Where to get PBM:Problem Investigation form, 'Problem Coordinator' field history. Capture Compare 'Problem Coordinator' field before and after update Event type inferred
	Known Error Promoted	The creation of a Known Error record linked to the problem investigation. This is a related record creation event.
Why it matters Indicates the formalization of the problem for broader communication and long-term tracking. Where to get Creation of a record in PBM:Known Error linked to the PBM:Problem Investigation ID. Capture Logged when PBM:Known Error record is created Event type explicit
	Post-Implementation Review Conducted	The completion of the PIR phase. Captured by a status transition out of a PIR state or the closure of a linked PIR Task.
Why it matters Directly supports 'Post Implementation Review Compliance' and process quality audits. Where to get PBM:Problem Investigation form, specific flag 'PIR Required' or completion of linked Task type 'PIR'. Capture Derived from PIR status completion or PIR Task closure Event type inferred
	Solution Database Updated	The transition of the record to the 'Solution Database' status, indicating a permanent fix has been proposed or identified.
Why it matters Tracks the progress of solution definition before implementation. Where to get PBM:Problem Investigation form, 'Status' field = 'Solution Database'. Capture Compare status field for transition to Solution Database Event type inferred

Recommended Optional

Extraction Guides

How to extract your problem management data from BMC Helix ITSM

Steps

Log in to BMC Helix ITSM Access the mid-tier or Smart IT interface using credentials with Problem Master or Report Administrator permissions.
Navigate to the Report Console From the Applications menu, select AR System Report Console. If using Smart IT, navigate to the Reporting dashboard and select 'Web Report'.
Create a New Report Click the New button (green plus icon) to initialize the report wizard.
Select the Data Source (Form) In the 'Form Name' field, search for and select PBM:AuditLogSystem (or PBM:Problem Investigation_AuditLog depending on version). Note: While the PBM:Problem Investigation form contains current case data, the Audit Log form is required to generate the row-by-row event history (e.g., reassignments, status changes) mandated by the data requirements.
Define the Report Name and Type Enter a descriptive title (e.g., 'Problem Management Event Log') and ensure the format is set to Web Report.
Add Columns (Attributes) Select the following fields from the Available Fields list and move them to the Selected Fields list:
- Original Request ID (maps to ProblemRecord)
- Submit Date (maps to EventTime)
- Fields Changed (maps to Activity)
- User (maps to User/Coordinator)
- Log Key 1 (often holds the raw Status value)
Configure Filters (Qualification) Click the Filter or Qualification tab. Construct a query to limit the scope:
- Set Form Name equal to "PBM:Problem Investigation" (to exclude Incident/Change audits).
- Set Submit Date to your desired range (e.g., >= 01/01/2023).
Save and Run Save the report configuration. Click Preview to verify data is returning, then click Export.
Export as CSV Select CSV (Comma Separated Value) as the export format. Ensure headers are included.
Secondary Export (Recommended for Attributes) Create a second simple report on PBM:Problem Investigation. Export Problem Investigation ID, Priority, ServiceCI, and Description. This 'Case Attribute' file can be joined with the Event Log in your analysis tool to populate the recommended static attributes (Priority, Service CI) which are not present in every audit log row.
Data Transformation (Post-Export) Before uploading to ProcessMind:
- Map Fields Changed values to the standard Activities (e.g., if Field Changed = "Status", use the value in Log Key 1 to determine if it is 'Investigation Commenced' or 'Root Cause Identified').
- Filter out non-process updates (e.g., cosmetic field updates) if not needed.

Configuration

Form Selection: PBM:AuditLogSystem is the primary source. Extracting PBM:Problem Investigation directly will only provide the current state, failing to capture the history of 'Coordinator Reassigned' or 'Workaround Defined'.
Date Filtering: Filter on Submit Date within the Audit form, not just the Case creation date, to capture recent activities on older cases.
Field 'Form Name': Crucial filter. The Audit System form is shared across ITSM. You MUST filter by Form Name = "PBM:Problem Investigation" to avoid mixing in Incident or Change logs.
Performance: The Audit Log table is very large. Limit exports to 3-6 month windows or filter strictly by Original Request ID prefixes (e.g., PBM%).
Permissions: Requires permission to view System Audit forms. If restricted, a System Administrator must run this export.

a Sample Query config

Form: PBM:AuditLogSystem
Type: Web Report (AR System Report Console)

// === SELECTION COLUMNS ===
// These fields form the raw event log structure
1. Original Request ID   (Alias: ProblemRecord)
2. Submit Date           (Alias: EventTime)
3. Submitter             (Alias: User)
4. Fields Changed        (Alias: Activity_Type)
5. Log Key 1             (Alias: New_Value)
6. Log Key 2             (Alias: Previous_Value)
7. Form Name             (Alias: Source_Module)

// === SEARCH QUALIFICATION (FILTER) ===
// Copy this logic into the Advanced Search or Qualification builder

('Form Name' = "PBM:Problem Investigation") AND
('Submit Date' >= "2023-01-01 00:00:00") AND
('Fields Changed' != $NULL$)

// === POST-EXPORT LOGIC (Context for Analyst) ===
// The Audit Log captures changes generically. You must map them:
// IF 'Fields Changed' CONTAINS "Status" AND 'Log Key 1' = "Under Investigation" -> Activity = "Investigation Commenced"
// IF 'Fields Changed' CONTAINS "Work Around" -> Activity = "Workaround Defined"
// IF 'Fields Changed' CONTAINS "PBM Coordinator" -> Activity = "Coordinator Reassigned"
// IF 'Fields Changed' = $NULL$ (Create Event) -> Activity = "Problem Record Logged"

Steps

Prerequisites Verification: Ensure you have read access (SELECT permissions) to the AR System database, specifically the PBM_Problem_Investigation and PBM_Problem_WorkLog views. Confirm your user account has access to the relevant Company/Support Group data.
Database Connection: Open your preferred SQL client (e.g., SQL Server Management Studio, DBeaver, or Oracle SQL Developer) and connect to the BMC Helix AR System database replica or reporting database.
Understand the Data Model: Identify the specific table or view names for your instance. While PBM_Problem_Investigation is standard, some customized environments might use PBM_Problem_Investigation_Join or similar. Verify column names for Problem_ID and Submit_Date.
Prepare the Query: Copy the SQL query provided in the 'Query' section below. This script combines the main problem record data with the work log history to create a transactional event log.
Configure Filters: Locate the WHERE clauses in the script (marked with comments like /* Filter by Date */) and update the date range to your desired extraction window (e.g., Submit_Date >= '2023-01-01').
Execute Extraction: Run the full query. Depending on the volume of problem records and work logs, this may take several minutes. Ensure your database client does not time out.
Data Validation: Check the results for specific key columns: ProblemRecord, Activity, and EventTime. Ensure no NULL values exist in these mandatory fields.
Export Data: Save the query results as a CSV file. Use standard encoding (UTF-8) and ensure headers are included.
Formatting for Upload: Open the CSV and verify date formats are consistent (ISO 8601 YYYY-MM-DD HH:MM:SS is recommended for ProcessMind). Remove any binary characters or excessive whitespace from text fields if observed.
Import to ProcessMind: Upload the cleaned CSV to ProcessMind, mapping the columns as defined in the 'Settings Overview'.

Configuration

Timeframe: Recommended extraction window is 3-6 months of data to balance performance and process visibility.
System Views: Primary views are PBM_Problem_Investigation (Header data) and PBM_Problem_WorkLog (Activity history).
Date Filtering: Filter primarily on Submit_Date of the Problem Investigation to keep complete cases, or EventTime for a strict timeframe snapshot.
Company Filter: If hosting multiple tenants, add AND Company = 'YourCompany' to all WHERE clauses to prevent data leakage.
Performance: The query uses UNION ALL which is efficient, but joining large CLOB/Text fields in WorkLog can be slow. Ensure database indexing on Problem_ID is utilized.

a Sample Query sql

/* Part 1: Problem Record Logged (Creation) */
SELECT
    P.Problem_ID AS ProblemRecord,
    'Problem Record Logged' AS Activity,
    P.Submit_Date AS EventTime,
    'BMC Helix' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    P.Assigned_Group AS SupportGroup,
    P.Priority AS Priority,
    P.PBM_Coordinator AS ProblemCoordinator,
    P.Generic_Category AS RootCauseCategory,
    P.ServiceCI AS ServiceCI,
    P.Investigation_Driver AS InvestigationDriver,
    P.Target_Date AS SLADueDate,
    (SELECT COUNT(*) FROM HPD_Help_Desk_Associations A WHERE A.Problem_ID = P.Problem_ID) AS RelatedIncidentCount,
    CASE WHEN P.Target_Date < P.Closed_Date THEN 'Yes' ELSE 'No' END AS IsSLABreached
FROM PBM_Problem_Investigation P
WHERE P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 2: Investigation Commenced (Status Transition) */
SELECT
    P.Problem_ID,
    'Investigation Commenced',
    /* Prefer explicit status history timestamp if available, else estimate from Last_Modified if current status matches */
    COALESCE(P.Status_History_Under_Inv_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Under_Inv_Time IS NOT NULL
   OR (P.Status = 1 AND P.Last_Modified_Date IS NOT NULL) /* Status 1 = Under Investigation */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 3: Root Cause Identified (Status Transition) */
SELECT
    P.Problem_ID,
    'Root Cause Identified',
    COALESCE(P.Status_History_Root_Cause_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Root_Cause_Time IS NOT NULL
   OR (P.Status = 2) /* Status 2 = Root Cause Identified */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 4: Solution Database Updated (Status Transition) */
SELECT
    P.Problem_ID,
    'Solution Database Updated',
    COALESCE(P.Status_History_Solution_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Solution_Time IS NOT NULL
   OR (P.Status = 3) /* Status 3 = Solution Database */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 5: Resolution Verified (Inferred from Completed Status) */
SELECT
    P.Problem_ID,
    'Resolution Verified',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Completed_Time IS NOT NULL
   OR (P.Status >= 4) /* Status 4 = Implemented/Completed */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 6: Problem Record Closed */
SELECT
    P.Problem_ID,
    'Problem Record Closed',
    P.Closed_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 5 /* Status 5 = Closed */
  AND P.Closed_Date IS NOT NULL
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 7: Problem Record Cancelled */
SELECT
    P.Problem_ID,
    'Problem Record Cancelled',
    P.Last_Modified_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 6 /* Status 6 = Cancelled */
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 8: Workaround Defined (From Worklog) */
SELECT
    P.Problem_ID,
    'Workaround Defined',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Work_Log_Type = 'Workaround' OR W.Description LIKE '%Workaround%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 9: Assigned to Support Group (From Worklog) */
SELECT
    P.Problem_ID,
    'Assigned to Support Group',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Assigned to Group%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 10: Coordinator Reassigned (From Worklog) */
SELECT
    P.Problem_ID,
    'Coordinator Reassigned',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Coordinator%' AND W.Description LIKE '%Change%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 11: Change Request Initiated (From Worklog or Description) */
SELECT
    P.Problem_ID,
    'Change Request Initiated',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Change Request%' OR W.Description LIKE '%CRQ%')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 12: Known Error Promoted (From Worklog) */
SELECT
    P.Problem_ID,
    'Known Error Promoted',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Known Error%' OR W.Work_Log_Type = 'Known Error')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 13: Post-Implementation Review Conducted */
SELECT
    P.Problem_ID,
    'Post-Implementation Review Conducted',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE (P.Status_Reason = 'PIR' OR P.Investigation_Driver = 'PIR')
  AND P.Status >= 4
  AND P.Submit_Date >= '2023-01-01'

Steps

Prerequisites: Ensure Python 3.x is installed on your extraction machine. You will need the requests and pandas libraries. Install them via pip install requests pandas.
API Access: Request a dedicated integration user account from your BMC Helix ITSM administrator. This user needs 'Problem Viewer' and 'AR System Administrator' (or equivalent API access) permissions.
Identify API Gateway: Obtain the base URL for your BMC Helix AR System REST API. It typically looks like https://[your-instance].onbmc.com/api/arsys/v1.
Field ID Mapping: BMC Helix uses internal Field IDs. While the script uses the useLabels feature to try and fetch human-readable names, you should verify the specific Field IDs for 'Status', 'Assigned Group', and 'Workaround' in your specific deployment using Developer Studio or by performing a test GET request.
Script Configuration: Update the CONFIG dictionary in the provided Python script. Set your URL, username, password, and the date range for extraction.
Primary Data Extraction: The script first queries the PBM:Problem Investigation form. This retrieves the base Problem Record details, creates the 'Problem Record Logged' event based on the Submit Date, and captures current attributes.
History Data Extraction: The script acts iteratively to fetch the audit trail. In BMC Helix, history is often stored in PBM:AuditLogSystem or accessible via the associations. The provided script queries the Audit form to capture state transitions (like Investigation Commenced) and field updates (like Assigned to Support Group).
Data Transformation: The script contains logic to map BMC Status codes (e.g., 'Under Investigation', 'Root Cause Identified') to the specific Activity names required by the process definition.
Validation: Run the script in a dry-run mode (fetching a small limit of records) to ensure field names match your customization. Check the console output for connection errors.
Execution: Run the full extraction. The script handles pagination automatically using the offset and limit parameters to avoid timeouts.
Output Generation: The script aggregates all events into a single DataFrame and exports them to a file named problem_management_event_log.csv.
Final Check: Open the CSV file and verify that the 'EventTime' column is properly formatted (ISO 8601 recommended) and that all 13 activity types are present before uploading to ProcessMind.

Configuration

API Endpoint: The AR System REST API is the standard interface. Ensure traffic is allowed on the relevant port (usually 443).
Pagination: The script uses a default batch size of 1000. Increase or decrease this based on your network latency and server timeout settings.
Date Filtering: The extraction filters by Submit Date for the main record. Ensure the date format in the query matches the AR System format (often epoch or specific string format depending on version).
Field Selection: Only necessary fields are requested to reduce payload size. Adding description or attachment fields can significantly slow down extraction.
Authentication: JWT (JSON Web Token) authentication is used. The token expires, so the script includes logic to acquire a token before requests.
Status Mapping: BMC uses integer IDs for status values (e.g., 0, 10, 20). The script maps these to human-readable activities. Verify these mappings against your specific ITSM configuration.

a Sample Query python

import requests
import json
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># Configuration
CONFIG = {
    class="hl-string">"base_url": class="hl-string">"https://[your-instance].onbmc.com/api/arsys/v1",
    class="hl-string">"username": class="hl-string">"[API_User]",
    class="hl-string">"password": class="hl-string">"[API_Password]",
    class="hl-string">"start_date": class="hl-string">"2023-01-01T00:00:00.000+0000",
    class="hl-string">"output_file": class="hl-string">"problem_management_event_log.csv",
    class="hl-string">"batch_size": 1000
}

class=class="hl-string">"hl-comment"># Status Map (Standard BMC Helix PBM Status values)
STATUS_MAP = {
    class="hl-string">"Draft": class="hl-string">"Problem Record Logged",
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Commenced",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Solution Database": class="hl-string">"Solution Database Updated",
    class="hl-string">"Solution Implemented": class="hl-string">"Resolution Verified",
    class="hl-string">"Completed": class="hl-string">"Resolution Verified",
    class="hl-string">"Rejected": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Cancelled": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed"
}

class=class="hl-string">"hl-comment"># Global Session
session = requests.Session()

def login():
    url = fclass="hl-string">"{CONFIG['base_url']}/jwt/login"
    headers = {class="hl-string">"Content-Type": class="hl-string">"application/x-www-form-urlencoded"}
    data = {
        class="hl-string">"username": CONFIG[class="hl-string">"username"],
        class="hl-string">"password": CONFIG[class="hl-string">"password"]
    }
    response = session.post(url, headers=headers, data=data)
    if response.status_code == 200:
        session.headers.update({class="hl-string">"Authorization": fclass="hl-string">"AR-JWT {response.text}"})
        print(class="hl-string">"Authentication successful.")
    else:
        raise Exception(fclass="hl-string">"Login failed: {response.text}")

def fetch_records(form_name, fields, query_string):
    all_entries = []
    offset = 0
    
    while True:
        url = fclass="hl-string">"{CONFIG['base_url']}/entry/{form_name}"
        params = {
            class="hl-string">"q": query_string,
            class="hl-string">"fields": fclass="hl-string">"values({','.join(fields)})",
            class="hl-string">"offset": offset,
            class="hl-string">"limit": CONFIG[class="hl-string">"batch_size"],
            class="hl-string">"useLabels": class="hl-string">"true"
        }
        
        resp = session.get(url, params=params)
        if resp.status_code != 200:
            print(fclass="hl-string">"Error fetching data: {resp.text}")
            break
            
        data = resp.json()
        entries = data.get(class="hl-string">'entries', [])
        if not entries:
            break
            
        for entry in entries:
            all_entries.append(entry[class="hl-string">'values'])
            
        offset += len(entries)
        print(fclass="hl-string">"Fetched {len(all_entries)} records from {form_name}...")
        
    return all_entries

def generate_event_log():
    class=class="hl-string">"hl-comment"># 1. Fetch Main Problem Records
    print(class="hl-string">"Fetching Problem Investigations...")
    pbm_fields = [
        class="hl-string">"Problem ID", class="hl-string">"Submit Date", class="hl-string">"Last Modified Date", class="hl-string">"Status", 
        class="hl-string">"Assigned Group", class="hl-string">"Priority", class="hl-string">"Problem Coordinator", 
        class="hl-string">"Description", class="hl-string">"Workaround", class="hl-string">"Investigation Driver"
    ]
    class=class="hl-string">"hl-comment"># Query syntax: class="hl-string">'Submit Date' > class="hl-string">"start_date"
    pbm_query = fclass="hl-string">"'Submit Date' > \"{CONFIG[class="hl-string">'start_date']}\class="hl-string">""
    
    problems = fetch_records(class="hl-string">"PBM:Problem Investigation", pbm_fields, pbm_query)
    
    event_log = []
    
    class=class="hl-string">"hl-comment"># Map of Problem ID to attributes for enrichment
    pbm_lookup = {}

    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        pbm_lookup[pid] = p
        
        class=class="hl-string">"hl-comment"># Event 1: Problem Record Logged (Creation)
        event_log.append({
            class="hl-string">"ProblemRecord": pid,
            class="hl-string">"Activity": class="hl-string">"Problem Record Logged",
            class="hl-string">"EventTime": p.get(class="hl-string">"Submit Date"),
            class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
            class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
            class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
            class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
            class="hl-string">"LastDataUpdate": datetime.now().isoformat()
        })

    class=class="hl-string">"hl-comment"># 2. Fetch Audit Logs / History
    class=class="hl-string">"hl-comment"># Note: Fetching PBM:AuditLogSystem or PBM:Problem Investigation_AuditLog
    class=class="hl-string">"hl-comment"># We filter by the Problem IDs we just fetched to optimize
    print(class="hl-string">"Fetching Audit Logs...")
    
    class=class="hl-string">"hl-comment"># In a real scenario, chunk this query if too many IDs, here simplified
    class=class="hl-string">"hl-comment"># We look for field changes relevant to our activities
    audit_fields = [class="hl-string">"Original Request ID", class="hl-string">"Fields Changed", class="hl-string">"Log Date", class="hl-string">"User", class="hl-string">"New Value"]
    
    class=class="hl-string">"hl-comment"># Iterate through problems to get history (Alternative: fetch bulk audit if API allows complex ORs)
    class=class="hl-string">"hl-comment"># For this script, we assume we fetch audit based on the main form query logic mapping
    class=class="hl-string">"hl-comment"># WARNING: Fetching audit for all records can be slow. 
    
    class=class="hl-string">"hl-comment"># For demonstration, we simulate fetching audit entries. 
    class=class="hl-string">"hl-comment"># In production, query class="hl-string">'PBM:Problem Investigation_AuditLog' where class="hl-string">'Original Request ID' IN (...)
    
    class=class="hl-string">"hl-comment"># Placeholder for audit data retrieval logic
    class=class="hl-string">"hl-comment"># Simulating a loop over retrieved problems to get their specific audit trails
    class=class="hl-string">"hl-comment"># This is a logical representation; in high volume, use a bulk export method
    
    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        
        class=class="hl-string">"hl-comment"># Query specific audit form for this problem
        class=class="hl-string">"hl-comment"># Using PBM:Problem Investigation_AuditLog as the standard history container
        audit_query = fclass="hl-string">"'Original Request ID' = \"{pid}\class="hl-string">""
        class=class="hl-string">"hl-comment"># We only need specific fields changed
        audit_entries = fetch_records(class="hl-string">"PBM:Problem Investigation_AuditLog", audit_fields, audit_query)
        
        for audit in audit_entries:
            fields_changed = audit.get(class="hl-string">"Fields Changed", class="hl-string">"")
            new_val = audit.get(class="hl-string">"New Value", class="hl-string">"")
            log_date = audit.get(class="hl-string">"Log Date")
            
            activity = None
            
            class=class="hl-string">"hl-comment"># Map Fields to Activities
            if class="hl-string">"Status" in fields_changed:
                class=class="hl-string">"hl-comment"># Map status string to activity
                activity = STATUS_MAP.get(new_val)
                
            elif class="hl-string">"Assigned Group" in fields_changed:
                activity = class="hl-string">"Assigned to Support Group"
                
            elif class="hl-string">"Workaround" in fields_changed:
                activity = class="hl-string">"Workaround Defined"
                
            elif class="hl-string">"Problem Coordinator" in fields_changed:
                activity = class="hl-string">"Coordinator Reassigned"
                
            elif class="hl-string">"Infrastructure Change ID" in fields_changed or class="hl-string">"Change Request" in fields_changed:
                activity = class="hl-string">"Change Request Initiated"
                
            elif class="hl-string">"Known Error" in fields_changed:
                activity = class="hl-string">"Known Error Promoted"

            class=class="hl-string">"hl-comment"># PIR Inference: If status moves to class="hl-string">'Closed' and PIR task exists (simplified here to Status)
            if activity == class="hl-string">"Problem Record Closed" and p.get(class="hl-string">"PIR Required") == class="hl-string">"Yes":
                 class=class="hl-string">"hl-comment"># Insert PIR event just before close if not explicitly found
                 event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": class="hl-string">"Post-Implementation Review Conducted",
                    class="hl-string">"EventTime": log_date, class=class="hl-string">"hl-comment"># Same time as close for this logic
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

            if activity:
                event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": activity,
                    class="hl-string">"EventTime": log_date,
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"), class=class="hl-string">"hl-comment"># Use current or historical if parsed
                    class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
                    class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Sorting
    if not df.empty:
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ProblemRecord', class="hl-string">'EventTime'])
        
        class=class="hl-string">"hl-comment"># Export
        df.to_csv(CONFIG[class="hl-string">'output_file'], index=False)
        print(fclass="hl-string">"Extraction complete. Data saved to {CONFIG['output_file']}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    try:
        login()
        generate_event_log()
    except Exception as e:
        print(fclass="hl-string">"An error occurred: {e}")

Your Problem Management Data Template

Your Problem Management Data Template

Problem Management Attributes

Problem Management Activities

Extraction Guides

BMC Helix AR System Report Console Export

Steps

Configuration

a Sample Query config

Direct SQL Query on AR System Database Views

Steps

Configuration

a Sample Query sql

Python Extraction via AR System REST API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Fix Problem Management Bottlenecks Today

Your Problem Management Data Template

Your Problem Management Data Template

Problem Management Attributes

Problem Management Activities

Extraction Guides

BMC Helix AR System Report Console Export

Steps

Configuration

a Sample Query config

Direct SQL Query on AR System Database Views

Steps

Configuration

a Sample Query sql

Python Extraction via AR System REST API

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Fix Problem Management Bottlenecks Today