Freshservice reporting infrastructure

Executive and leadership reporting on Freshservice, built by connecting Power BI directly to the Freshservice REST API rather than living inside Freshservice's native reports. Reports are published to a Power BI workspace with scheduled refresh, so leadership questions get answered against current data instead of a hand-built export. This is the layer presented at leadership forums.

How it is built

• Power BI connects straight to the Freshservice REST API. Queries hit the API endpoints directly and shape the results in Power Query. No intermediate warehouse, no ETL job to operate, no separate copy of the data to keep in sync.
• Reports published to a workspace. The report and its semantic model live in the Power BI service rather than on a desktop file, so leadership consumes them from the service.
• Scheduled refresh keeps the published reports current on their own cadence. Nothing needs to be run by hand.

Choosing the API over Freshservice's native reporting is what made the rest possible: measures, cross-entity relationships, and report layouts are all defined in Power BI, so the reporting is not limited to what the vendor's report builder exposes.

What the reports cover

• Volume and trend Ticket counts by category, year-over-year trend, seasonality, regional distribution.
• SLA and resolution First-response time, resolution time, SLA attainment by priority and category.
• Category trending Which IT categories are growing, which are shrinking, where to focus.
• Asset reporting Warranty expiry pipeline, refresh-cycle visibility, vendor concentration, regional asset distribution.

Relationship to Fabric F64

The reporting started on Power BI Pro. When the Fabric F64 capacity was approved and rolled out, the workspace moved onto that capacity alongside the broader dataset estate the BI team maintains for the customer-facing multi-manufacturer multi-tenant reporting.

That is a hosting and licensing change, not an architecture change. The reports still pull from the Freshservice API on a refresh schedule the same way they did on Pro.

What this demonstrates

• Going to the API instead of accepting the vendor's reporting ceiling. Freshservice ships native reports; building on the REST API instead meant the measures, relationships, and layouts were defined where they could be changed, which is why the reporting could grow with the questions leadership actually asked.
• Operationally quiet by design. Direct API connection plus scheduled refresh means no pipeline to babysit, no intermediate store to reconcile, and no second copy of the data to drift.
• Reporting for an executive audience specifically: SLA attainment, category trend, and warranty pipeline framed for the decisions leadership makes, not the diagnostics an IT team runs.
• Long-running production ownership. Years in continuous service and still the reporting layer for leadership, across a Power BI Pro to Fabric F64 capacity move.

Not to be confused with

The AI-augmented IT operations platform also reads Freshservice, but it is separate, later work: a different system for a different audience (the IT team, not leadership) on its own Postgres backbone. This reporting layer predates it and the two do not depend on each other.