Issue Burndown to Power BI

Overview

Nightly cloud flow that snapshots every issue (open + closed, excluding pull requests) from a configured GitHub repository and writes each one as a row into a dedicated Dataverse table. The table becomes the source-of-truth historical dataset that Power BI reports can bind to for burndown charts, label distribution, assignee workload, and velocity trending.

Ships Off in the Stopped state. Activating it requires only (1) authorizing the GitHub and Dataverse connection references and (2) setting the two environment variables to point at the target org/repo.

Use Case

Product, engineering, and executive stakeholders want historical views of GitHub issue activity that can be sliced over time (burndown, label distribution, assignee load). GitHub's native Insights tab gives point-in-time views; it doesn't support long-range analytical queries or cross-report joins.

This flow creates an append-only snapshot dataset in Dataverse so Power BI can model the data using its own time intelligence and DAX. Each nightly run adds a fresh snapshot row per issue stamped with flowlibs_snapshotdate, which allows burndown-style charts to plot open/closed counts by day, label, or assignee.

The flow is ideal for teams that:

• Product managers tracking issue burndown and velocity trends
• Engineering leaders monitoring assignee workload distribution
• Executives reviewing label distribution and long-range issue activity
• Teams needing historical GitHub data outside the native Insights tab
• Power BI authors building DAX-driven time-intelligence reports

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Point at a different repo

Update the two env var values (flowlibs_GitHubOwner and flowlibs_GitHubRepository) in the solution. No flow changes required.

Monitor multiple repos

Replace Init varGitHubOwner and Init varGitHubRepo with a delimited-list env var plus a Select expanded to an array, and wrap the GetIssues call in a parent Apply to each.

Get beyond 100 issues

Swap GetIssues for the connector's HttpRequest action with per_page=100 and page=N in a Do until loop (exit when length(body) < 100).

Filter out triaged issues

Add a label filter on GetIssues by setting the labels query parameter (comma-delimited list).

Skip rewriting labels/assignees as JSON

Replace the string(...) expressions with @{join(select(labels, 'name'), ',')} for a flat CSV instead of a JSON array.

Change the schedule

Edit the recurrence block — daily is the minimum meaningful cadence for a burndown curve; hourly produces too much data for Power BI imports.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

concat(variables('varRepoFullName'), '#', string(items('Apply_to_each_Issue')?['number']), '@', formatDateTime(variables('varSnapshotDate'), 'yyyyMMddHHmmss'))

equals(coalesce(string(items('Apply_to_each_Issue')?['pull_request']), ''), '')

if(greater(length(coalesce(items('Apply_to_each_Issue')?['title'], '')), 500), substring(items('Apply_to_each_Issue')?['title'], 0, 500), coalesce(items('Apply_to_each_Issue')?['title'], ''))

string(coalesce(items('Apply_to_each_Issue')?['labels'], json('[]')))