Connect Microsoft Power BI to QPR ProcessAnalyzer

This guide explains how to connect Microsoft Power BI to QPR ProcessAnalyzer using the Power Query Web.Contents function. It walks you through creating the data source, building the semantic model, setting privacy levels, defining column data types, and producing your first report.

The connection works by authenticating against the QPR ProcessAnalyzer REST API to obtain an access token, then running an expression query against a selected model to retrieve data as a table.

Overview

The connection is built entirely in the Power Query editor using a single M query. The query performs three steps:

Get an access token: sends the username and password to the token endpoint using the OAuth password grant type and reads the returned access_token.
Run an expression query: sends a JSON request body (dimensions, values, ordering, etc.) to the api/expression/query endpoint, using the access token as a Bearer token.
Parse and shape: converts the returned JSON into a Power BI table.

Step 1: Create Data Source

Open Power BI Desktop.
On the Home ribbon, click Get data → Blank query.
- Alternatively, choose Get data → More... → Other → Blank Query → Connect.
The Power Query Editor opens with a new empty query named Query1.
In the toolbar, click Advanced Editor.
Delete any existing content and paste the M script below.

Power Query Script

let
    // ================= Configuration =================
    BaseUrl  = "https://server.onqpr.com/qprpa/",
    ModelId  = 123,
    UserName = "qpr",
    Password = "demo",
    RequestBody = [
        Dimensions = {
            [
                Name       = "Company Code",
                Expression = "Column(""Company Code"")"
            ]
        },
        Values = {
            [
                Name                = "Count",
                AggregationFunction = "count"
            ]
        },
        Ordering = {
            [
                Name      = "Count",
                Direction = "Descending"
            ]
        },
        Root             = "Cases",
        ModelId          = ModelId,
        ContextType      = "model",
        ProcessingMethod = "dataframe"
    ],

    // ================= Step 1: Get access token =================
    TokenBody = Uri.BuildQueryString([
        grant_type = "password",
        username   = UserName,
        password   = Password
    ]),
    TokenResponse = Web.Contents(
        BaseUrl,
        [
            RelativePath = "token",
            Headers = [
                #"Content-Type" = "application/x-www-form-urlencoded",
                #"Accept"       = "application/json"
            ],
            Content = Text.ToBinary(TokenBody)
        ]
    ),
    TokenParsed = Json.Document(TokenResponse),
    AccessToken = TokenParsed[access_token],

    // ================= Step 2: Run query =================
    QueryResponse = Web.Contents(
        BaseUrl,
        [
            RelativePath = "api/expression/query",
            Headers = [
                #"Content-Type"  = "application/json",
                #"Accept"        = "application/json",
                #"Authorization" = "Bearer " & AccessToken
            ],
            Content = Json.FromValue(RequestBody)
        ]
    ),
    Parsed = Json.Document(QueryResponse),
    AsTable = Table.FromRecords(Parsed),

    // ================= Step 3: Set column types =================
    TypedTable = Table.TransformColumnTypes(
        AsTable,
        {
            {"Company Code", type text},
            {"Count",        Int64.Type}
        }
    )
in
    TypedTable

Update the Configuration section to match your environment:
- BaseUrl – your QPR ProcessAnalyzer base URL (keep the trailing slash).
- ModelId – the numeric ID of your model.
- UserName and Password – your QPR ProcessAnalyzer credentials.
Adjust the RequestBody to select the dimensions, values, and ordering you need.
Click Done to close the Advanced Editor.
Rename the query (right-click the query in the Queries pane → Rename).

Data types

The following example shows how to convert different data types in the PowerBI query.

TypedTable = Table.TransformColumnTypes(
	AsTable,
	{
		{"TextColumn", type text},
		{"IntegerColumn", Int64.Type},
		{"DecimalColumn", type number},
		{"DateColumn", type date},
		{"BooleanColumn", type logical}
	}
),

Step 2: Configure Privacy Settings

Because the query passes data (credentials and a token) from one Web.Contents call into another, Power BI's Privacy Level checks can block the query or trigger a "Formula.Firewall" error. You must configure privacy settings correctly.

In the Power Query Editor, go to File → Options and settings → Options.
Under Current File, select Privacy.
Choose Combine data according to your Privacy Level settings for each source, and set the source privacy level to Public or Organizational as appropriate for your organization.
Click OK.

Setting credentials for the data source

When the query runs for the first time, Power BI may prompt for credentials for the base URL:

If prompted, select Anonymous as the authentication method (authentication is handled inside the query via the token).
Set the privacy level for the URL to Organizational (or Public).
Click Connect.

Step 3: Create First Report

Switch to the Report view (left sidebar).
From the Visualizations pane, select a visual, for example a Clustered bar chart.
From the Data pane, drag fields onto the visual:
- Drag Company Code to the Y-axis (or Axis).
- Drag Count to the X-axis (or Values).
Adjust formatting (title, colors, data labels) in the Format pane.
Add slicers or filters as needed (for example, a slicer on Company Code).
Save the report: File → Save As and choose a location for the .pbix file.

Refreshing Data

Manual refresh: In Power BI Desktop, click Refresh on the Home ribbon.
Scheduled refresh (Power BI Service): After publishing, configure a scheduled refresh. Because the query calls a web API, you may need an appropriate gateway configuration and correctly configured credentials/privacy levels in the service.

Caveats and Limitations

Before implementing this integration, be aware of the following limitations. They affect how up to date the data is, how access is controlled, and how filtering behaves.

Reports are not real time

Data shown in Power BI is a snapshot taken at the time of the last data load. It is not a live connection to QPR ProcessAnalyzer. The data is updated only when a refresh is performed, either:

Manually – by clicking Refresh in Power BI Desktop, or
On a schedule – by configuring a scheduled refresh in the Power BI Service.

As a result, reports may not reflect the most recent changes in the underlying QPR ProcessAnalyzer model until the next refresh runs.

Shared (common) QPR ProcessAnalyzer credentials

The connection authenticates using a single set of QPR ProcessAnalyzer credentials embedded in the query, rather than each report user's individual account. This has important consequences:

All Power BI users effectively see data through the same QPR ProcessAnalyzer account, regardless of who they are.
User-specific permissions and per-user access restrictions defined in QPR ProcessAnalyzer are not applied to individual Power BI users.
Any access control must be handled on the Power BI side (for example, workspace permissions or row-level security), not through the QPR ProcessAnalyzer account.

Source data filtering is not applied

Filters applied to cases or events on the QPR ProcessAnalyzer side cannot be applied through this integration. The query retrieves data according to the defined dimensions and values without any interactive source-level filtering.

Only filtering performed on the Power BI side (slicers, visual filters, page/report filters) takes effect.
This means the full result set defined by the query is always retrieved before Power BI filtering is applied, which can affect the volume of data transferred and report performance.
To limit data at the source, you must change the query itself (the RequestBody dimensions and values) rather than rely on interactive filtering.