Connecting Microsoft Power BI to Cisco Unified Communications Manager (CUCM) allows organizations to transform raw call logs into actionable business intelligence.
However, because Cisco uses a proprietary database structure, a direct connection is rarely straightforward. This guide outlines the technical workflow for establishing a stable data pipeline, designing a robust schema, and decoding complex Cisco metrics.
For best practices guide on using Power BI for UC analytics, see our Using Power BI for Unified Communications (UC) Analytics: Build vs Buy Guide.
By default, CUCM may not be logging the diagnostic data Power BI needs. You must enable these records within the Cisco Unified CM Administration interface:
Navigate to System > Service Parameters.
Select your server and the Cisco CallManager service.
Set CDR Enabled Flag to True.
Set Call Diagnostics Enabled to Enabled Only When CDR Enabled Flag is True.
Note: If you want to track abandoned or missed calls, ensure CDR Log Calls with Zero Duration is also set to True.
Cisco does not allow a direct "DirectQuery" or "Import" via standard SQL to the active production database to prevent performance degradation. You have three primary paths:
CUCM can be configured to push CDR files to an SFTP server. Power BI then connects to the SFTP folder. This is the most common "manual" build method but requires complex Power Query logic to combine thousands of small CSV files.
Best for pulling "Dimension" data (user lists, device names, line configurations). This requires a specialized script or connector to handle the XML response. It is less ideal for high-volume call records due to performance throttling on the Cisco side.
For enterprise-grade reliability, tools like MetroLink UC Connector automate the extraction and normalization process, delivering a report-ready SQL schema directly to Power BI.
Cisco data requires significant "cleaning" before it can be used in visualizations:
Epoch Time Conversion: Cisco stores time in Unix Epoch format. In Power Query, use: #datetime(1970, 1, 1, 0, 0, 0) + #duration(0, 0, 0, [dateTimeOrigination]).
Cause Code Mapping: You must map origCause_value (e.g., 16) to readable text (e.g., "Normal Clearing").
Call Stitching: Use the GlobalCallID to link multiple call legs into a single customer journey.
To avoid performance lag, structure your Power BI model as a Star Schema. This separates high-volume call events from descriptive labels.
| Fact Tables (Quantitative) | Dimension Tables (Descriptive) |
|---|---|
| Fact_Calls: GlobalCallID, Duration, Timestamps, Original Party. | Dim_Users: Names, Departments, and Hierarchy. |
| Fact_Quality: Jitter, Latency, and Packet Loss (from CMRs). | Dim_Devices: IP Phone models, Softphones, and Gateways. |
| Fact_Queues: Hold times and abandonment counts. | Dim_CauseCodes: Translation of Cisco numeric codes. |
Once your schema is set, you can calculate the Answer Success Rate (ASR) to monitor system health:
ASR % =
DIVIDE(
CALCULATE(COUNT(Fact_Calls[GlobalCallID]), Fact_Calls[Duration] > 0),
COUNT(Fact_Calls[GlobalCallID])
)
Manually building ETL pipelines for Cisco CDRs is time-consuming. Expo XT UC Analytics provides a turnkey solution with pre-built Cisco dashboards, AI-driven insights, and automated data processing.
It is not recommended. DirectQuery against a production Cisco database can impact call processing performance. It is safer to use an "Import" model via a staging database or a tool like Metropolis' MetroLink for Power BI.
How often does the data refresh?Cisco typically generates CDR files every minute. With an optimized Power BI pipeline using Incremental Refresh, you can achieve near real-time visibility.
Does this work with Webex Calling?While the concepts are similar, connecting Webex Calling to Power BI uses a different API and schema than on-premises CUCM. For hybrid environments, we recommend a unified data layer to combine both sources.
