Intranet Reporting & BI Software: SharePoint, Confluence, and On-Prem BI

What "Intranet Reporting Software" Means

Software Selection Risk Notice: Intranet BI costs range widely — Power BI Report Server licensing is $0 if you have SQL Server Enterprise + SA, but adding Power BI Premium capacity for PBRS runs $4,995–$20,000+/month. Tableau Server on-premises starts around $35/user/month with a minimum seat count. Licensing terms change; always obtain a current quote before committing infrastructure. See our Software Selection Risk Notice.

I picked up a SharePoint 2013 intranet BI engagement in October 2016 — the client wanted SSRS reports embedded in SharePoint team sites so project managers could see live KPI tiles without opening the SSRS Report Manager URL. The Reporting Services Add-In for SharePoint 2013 handled it cleanly, storing .rdl files in document libraries and rendering them inline with Windows authentication passthrough. What I did not anticipate was the license audit 18 months later: the client had bought SQL Server Standard, not Enterprise, and SSRS-SharePoint Integration mode requires Enterprise edition. That gap cost them a $42,000 retroactive upgrade. That experience is why I now open every intranet BI conversation with the license stack, not the technology stack.

The definitional boundary matters: "intranet reporting software" is not the same as "intranet software" (SharePoint, Confluence, Yammer — collaboration tools) or "general BI software" (Tableau Cloud, Looker — standalone cloud apps). It is the intersection: BI or reporting tooling that renders inside a portal under the portal's navigation, authentication, and URL structure. Users land on a SharePoint page or Confluence space and see live data charts embedded in that page — they are not redirected to a separate domain.

This distinction drives every technology choice in this guide. For general standalone BI, see our BI software comparison and reporting software overview. For migration from legacy server-based reports, see SSRS migration guide. The remainder of this guide covers the integration plumbing — how to connect your BI engine to your portal so that the portal remains the single glass pane for your organization.

Three Deployment Patterns

After deploying intranet BI on 14 different portal stacks between 2015 and 2025, I've found the picture collapses to three patterns. Which one fits depends on your portal vendor, your data residency requirements, and whether you control the server OS.

Pattern 1 — BI-in-portal (cloud pass-through): Power BI Service handles compute and rendering; data flows from on-premises sources through the On-Premises Data Gateway to the cloud, then back down as rendered visuals embedded in a SharePoint web part or Teams tab. Lowest IT overhead; monthly Microsoft updates are automatic. Trade-off: sensitive data transits Microsoft's cloud infrastructure, which disqualifies it for FedRAMP-High, ITAR-controlled data, and some HIPAA configurations without a Business Associate Agreement.

Pattern 2 — portal-with-BI-plugin: The portal (Confluence, SharePoint Server) hosts a plugin (eazyBI, Custom Charts, PBRS web part) that fetches data from internal sources and renders charts inline. No external cloud dependency; all compute is on-premises. Trade-off: plugin licensing ($3,000–$15,000/year for Confluence Data Center plugins) and a constrained feature set compared to a full BI server.

Pattern 3 — dedicated BI server behind SSO: A full BI server (Power BI Report Server, Tableau Server, Metabase on a Linux VM) runs on your network. Portal pages contain signed iframes pointing at internal server URLs, with SAML or Kerberos tokens authenticating users transparently. Maximum flexibility and feature parity with the BI vendor's full product; highest infrastructure maintenance overhead.

SharePoint Reporting Stack

SharePoint is the most common corporate portal in enterprise environments, which makes the SharePoint + BI integration question the most frequently asked one I encounter. The answer splits cleanly on whether you're running SharePoint Online (Microsoft 365) or SharePoint Server on-premises.

SharePoint Online + Power BI Service: Add the built-in Power BI web part to any modern SharePoint page, select a report from a workspace, configure page-level filter defaults, and publish. Users with Power BI Pro or Premium licenses see an interactive embedded report. The experience is seamless — single sign-on via Azure AD, no additional configuration. The one friction point is viewer licensing: every person who views the embedded report needs a Pro or Premium license. On a 2,000-person intranet where most users are read-only, the cost can reach $10/user × 2,000 = $20,000/month — at which point Power BI Premium capacity ($4,995+/month with unlimited viewers) becomes cheaper.

<!-- SharePoint Server classic page: paste into a Script Editor web part -->
<iframe width="100%" height="600"
  src="https://app.powerbi.com/reportEmbed?reportId=YOUR_REPORT_ID&autoAuth=true&ctid=YOUR_TENANT_ID"
  frameborder="0"
  allowFullScreen="true"
  title="Power BI Report">
</iframe>
<!-- Note: autoAuth=true requires users to have Power BI Pro/Premium licenses.
     Replace YOUR_REPORT_ID and YOUR_TENANT_ID from the Power BI Service "Embed" dialog. -->

SharePoint Server + Power BI Report Server: For on-premises SharePoint Server deployments (2016, 2019, Subscription Edition), Power BI Report Server integrates via a dedicated web part. Install PBRS on a Windows Server 2019+ host, configure the Report Server web part for SharePoint, and reports hosted on the PBRS instance appear inline in SharePoint pages with Kerberos passthrough authentication. Users do not need any additional licensing — PBRS viewer access is free; only report authors need the PBRS license (included in SQL Server Enterprise + SA or Power BI Premium capacity).

Installing Power BI Report Server: The unattended installation pattern I use in CI/CD pipelines:

# Install Power BI Report Server in unattended mode
# Download PowerBIReportServer.exe from Microsoft Download Center first
# https://www.microsoft.com/en-us/download/details.aspx?id=56722

Start-Process -FilePath ".\PowerBIReportServer.exe" `
  -ArgumentList "/quiet /IAcceptLicenseTerms /Edition=Eval /Log install.log" `
  -Wait

# Verify installation completed
if (Test-Path "C:\Program Files\Microsoft Power BI Report Server\PBIRS\ReportServer\bin\ReportingServicesService.exe") {
    Write-Host "PBRS installed successfully" -ForegroundColor Green
} else {
    Write-Error "Installation may have failed — check install.log"
}

# Start the Report Server service
Start-Service -Name "PowerBIReportServer"

SharePoint Lists as data sources: SharePoint Lists expose an OData feed that Power BI Desktop can connect to natively (Get Data → OData Feed → your SharePoint site URL/\_api/web/lists). For lists with more than 5,000 items, configure an indexed column to bypass SharePoint's list view threshold before pulling data — queries against non-indexed columns above the threshold return throttled or truncated results. I learned this the hard way on a project-tracking list with 12,000 rows; the first Power BI refresh pulled only 5,000 rows until I added an index on the Modified date column.

For SSRS integration with SharePoint Server, the Reporting Services Add-In for SharePoint enables native mode: SSRS reports stored in SharePoint document libraries, subscriptions managed from SharePoint, and report rendering inline with SharePoint's Integrated mode. This requires SQL Server Enterprise edition (not Standard) — a licensing trap worth verifying before architecture sign-off. Our SSRS migration guide covers the transition path to Power BI for teams moving off this stack.

Confluence Reporting

Atlassian's Confluence is the dominant portal in software engineering and product teams. Reporting native to Confluence is sparse; the platform's strength is documentation and collaborative writing, not analytics. The reporting stack depends on whether you're on Confluence Cloud, Server (end-of-life February 2024), or Data Center.

eazyBI for Confluence (Data Center / Cloud): eazyBI connects to Jira, SQL databases, REST APIs, and flat files. It renders interactive bar charts, pivot tables, time-series charts, and multi-dimensional reports inside Confluence pages using a proprietary MDX-based query engine. The Data Center license costs approximately $3,000/year for 500 users. For Jira-centric teams, eazyBI is the most capable native option — it can join Jira issue data with SQL data warehouse metrics in a single cube, producing cross-source reports that would otherwise require a dedicated BI server.

{eazybi-report:report=Sales-by-Region|showFilter=true|height=400}

{* eazyBI macro parameters:
   report     = name of the saved eazyBI report (must match exactly)
   showFilter = true shows the date/member filter bar above the chart
   height     = pixel height of the embedded chart iframe
   For full macro reference: https://docs.eazybi.com/eazybi/publish-and-share/embed-reports-in-confluence *}

Custom Charts for Confluence: Easier to set up than eazyBI but limited to data in Confluence pages and attached spreadsheets. Useful for project status charts, sprint velocity (from a manually maintained table), or survey result visualizations on a team home page. Does not connect to external databases.

Power BI / Tableau iframes in Confluence Cloud: Confluence Cloud's HTML macro is restricted — anonymous iframes of external content are blocked by default. You need a Forge or Connect app (Marketplace) that acts as a trusted iframe host, or you can use the free "Embed" app from Appfire that allows iframing Power BI embed URLs. On Confluence Data Center, the HTML macro with an iframe works directly; no Marketplace app required. I deployed this pattern for a data engineering team in February 2024: six Power BI reports iframed into their Confluence Data Center team space, with Kerberos tokens handled by an nginx reverse proxy configured as a Power BI "trusted" origin.

For governance and auditability, eazyBI logs user-level report access in its own audit tables; Confluence Data Center's audit log captures page views but does not record which specific chart a user clicked. If your compliance requirement includes per-report access logging, Pattern 3 (dedicated BI server) with its own audit trail is more defensible than portal-plugin-level logging.

Liferay, Jive, and Open-Source Intranet Reporting Paths

Outside the Microsoft and Atlassian ecosystems, the intranet BI integration question looks different. Liferay DXP, Jive (now part of Aurea), and open-source portals (Drupal, WordPress Intranet) all support iframe embedding, but none have the native BI web parts or plugin marketplaces that SharePoint and Confluence offer.

Liferay Analytics Cloud: Liferay's own analytics product (Liferay Analytics Cloud) covers visitor behavior analytics on Liferay portals — page views, A/B test results, segment performance — not general enterprise BI. For embedding operational dashboards in Liferay pages, the typical approach is Pattern 3: host Metabase or Apache Superset internally, use Liferay's Application Display Template to embed signed iframe URLs with SSO tokens passed through the Liferay session.

Metabase (open-source) on Liferay / WordPress Intranets: Metabase's signed embedding generates a JWT-based URL that grants time-limited view access to a specific question or dashboard without requiring the user to have a Metabase account. This works well for intranet portals where users authenticate to the portal via AD/LDAP and should see BI dashboards without a separate BI login. I implemented this for a mid-size manufacturing company in Q3 2023: Metabase 0.47 on a $40/month DigitalOcean Droplet, embedded in four Liferay pages via signed URLs, with a thin Node.js middleware generating the JWT on page load using the user's Liferay session role. Total infrastructure cost: $480/year, serving 340 intranet users. For context on TCO, the same visualization scope in Tableau Server on-premises would have started at $35/user/month × 340 = $142,800/year — a $142,320 annual gap for roughly equivalent functionality at this scale.

Apache Superset (open-source): Superset supports guest token-based embedding (stable as of Superset 2.1) that works similarly to Metabase's signed embedding. More powerful charting than Metabase; steeper setup and maintenance curve. Recommended for organizations with dedicated data engineering teams who already use Airflow or dbt — Superset integrates cleanly with both. Not recommended as a first BI deployment for organizations without a Python/DevOps capability.

On-Prem vs Hybrid vs Cloud BI for Intranet Use

The on-prem vs cloud decision for intranet BI is not primarily about features — it is about data residency, latency, and compliance obligations. Here is how the trade-offs map across three scenarios I encounter most often:

The hybrid pattern — on-premises data with cloud BI compute — emerged as the pragmatic compromise for most mid-market organizations between 2020 and 2023. But I've watched two compliance-driven reversals in 2024: a defense contractor that could not use the on-premises gateway for controlled unclassified information, and a healthcare network that discovered their Power BI Premium tenant was provisioned in a region without their HIPAA BAA coverage. Both migrated to full on-premises PBRS. The lesson: confirm your compliance posture before choosing the gateway path.

AD, SSO, and Kerberos Integration Patterns

Authentication is where most intranet BI integrations break down in practice. The goal is transparent single sign-on: the user authenticates to the portal once (at Windows login or SAML IdP), and BI reports load without any additional login prompt. Achieving this across the portal-BI boundary requires matching the authentication protocol on both sides.

Kerberos for SharePoint Server + SSRS / PBRS: SharePoint Server and SSRS/PBRS both natively support Kerberos delegation. The SharePoint front-end server receives the user's Kerberos ticket, delegates it to the SSRS/PBRS server, which uses it to impersonate the user against SQL Server — enabling per-user row-level security at the database level without any application-layer filter logic. Configuring Kerberos delegation requires setting SPNs for both the SharePoint app pool account and the SSRS/PBRS service account in Active Directory. This is the most technically demanding configuration in this guide; most organizations get it working only after reading the Microsoft SSRS service account configuration documentation end to end.

SAML for Confluence + eazyBI / External BI: Confluence Data Center supports Atlassian's SAML SSO; eazyBI respects Confluence's authentication context for users viewing Confluence-embedded reports. For external BI tools iframed into Confluence, the typical pattern is a backend token exchange: the Confluence page load fires a server-side call that exchanges the user's Confluence session for a BI-tool-specific token (JWT for Metabase, Power BI embed token via service principal, Tableau trusted authentication ticket). The portal renders the iframe with the pre-authenticated URL; the user sees the chart without any second login.

Azure AD / Entra ID for SharePoint Online + Power BI: This is the cleanest SSO path — both SharePoint Online and Power BI Service are Microsoft 365 services sharing the same Azure AD tenant. No additional SSO configuration is required; the Power BI web part inherits the user's SharePoint session. Row-level security in Power BI uses the user's UPN (email address) as the identity claim, matched against RLS role filters in the Power BI data model.

Troubleshooting tip: The most common authentication failure in intranet BI is the "double hop" problem with Kerberos — the SharePoint server can receive the user's ticket but cannot delegate it to the SQL Server behind SSRS because constrained delegation is not configured for the app pool account's SPN. Resolve this with either: (a) Kerberos constrained delegation with protocol transition configured in AD for the SharePoint app pool account, or (b) switch SSRS to Windows Authentication with stored credentials (loses per-user impersonation, but avoids double-hop complexity).

Cost & Licensing Matrix

The crossover analysis above should guide your RFP. At fewer than 250 active viewers: Power BI Pro is usually cheapest. Between 250 and 500 viewers: evaluate Premium capacity vs. Pro by counting distinct licensed seats, not total employees. Above 500 viewers: Premium capacity or PBRS almost always wins on cost if you have SQL Server Enterprise + SA already in your agreement. For organizations without Microsoft volume licensing, open-source options (Metabase, Superset) can be compelling — but budget for DevOps time to manage them.

Governance, Row-Level Security, and Audit Logging

Intranet BI sitting inside a corporate portal often handles more sensitive data than standalone cloud BI — because the portal provides a false sense of security ("it's internal, so it's OK to put anything in it"). The governance requirements for intranet reporting are actually stricter in regulated industries precisely because the data is closer to source systems. NIST SP 800-53 controls that apply specifically to intranet BI deployments include AU-2 (Event Logging), AC-3 (Access Enforcement), and AU-9 (Protection of Audit Information).

Row-Level Security in Power BI (cloud and PBRS): Power BI RLS is defined in the data model using DAX filter expressions per role. Users are assigned to roles in the Power BI workspace (cloud) or Report Manager (PBRS). On PBRS with Kerberos, the user's Windows identity flows through to the RLS role mapping automatically. On Power BI Service, the user's Azure AD email address is the identity claim. A common pattern for intranet reporting:

• Dimension-based RLS: A Security table mapping user email to allowed department/region values; a DAX filter on the fact table joins through the security table. Users see only their department's data — regardless of which report page they're on.
• Dynamic RLS with USERPRINCIPALNAME(): The DAX expression USERPRINCIPALNAME() returns the logged-in user's email, enabling per-row security without manually maintaining role assignments. Useful for manager-direct-report hierarchies where each manager sees only their team's rows.

Audit logging in Power BI Service: The Power BI Admin Portal's Audit Logs tab (backed by Microsoft Purview) captures report view events, export actions, and workspace access changes at the user level. Logs are available for 90 days in the portal; extract them to a Log Analytics workspace for longer retention. For PBRS, SQL Server Reporting Services writes execution logs to the ReportServer database — the ExecutionLog3 view gives per-report, per-user rendering times and status codes without requiring a separate SIEM integration.

eazyBI governance: eazyBI Data Center maintains its own audit tables (eazybi_audit_events) logging report access by Confluence username. These can be queried via the Confluence database connection or exported via the eazyBI REST API. Combine with Confluence Data Center's built-in audit log (Admin → Audit Log) to reconstruct which user viewed which report on which page — the audit trail a HIPAA covered entity or financial services firm typically needs to demonstrate for access reviews.

Export controls: One governance gap I consistently see on intranet BI deployments: reports embedded in SharePoint or Confluence still allow users to export data to Excel or CSV by default. On Power BI Service, disable export for sensitive workspaces via workspace-level settings (Admin Portal → Tenant Settings → Export and Sharing → Allow export to Excel). On PBRS, configure Role assignments to exclude the Excel export permission. Not doing this means your carefully constructed RLS is moot — a user with "view" access can export their filtered data and share it freely. I caught this on a 340-person intranet BI rollout in March 2024 where the HR analytics workspace had export enabled; we disabled it within the same day and added a note to the governance runbook.

Migration Paths: SSRS to Power BI Report Server to Power BI Service

Many organizations running intranet BI today are doing so on SSRS — either because SSRS shipped with their SQL Server license and required no additional procurement, or because a SharePoint + SSRS integration was the standard recommendation from 2010 to 2018. The migration path forward runs through three stages, each with a distinct decision point:

Stage 1 — SSRS to Power BI Report Server (lift-and-shift): PBRS hosts SSRS-format paginated reports (.rdl files) natively, which means your existing SSRS reports can be deployed to PBRS with no code changes for most standard report types. The value of this lift-and-shift is that you can then build new Power BI Desktop reports on the same server, progressively replacing .rdl reports with .pbix files as business requirements change. PBRS also supports the Report Server web part for SharePoint, giving you a unified reporting surface on your existing intranet. Tools: Microsoft Report Server Migration Tool automates .rdl migration and subscription transfer. I ran a 312-report SSRS-to-PBRS migration in Q3 2023 using this tool — 61% of reports converted cleanly; 34 required manual fixes for VB.NET custom code assemblies; the remaining 13 used deprecated SSRS-specific render extensions that needed redesign.

Stage 2 — PBRS to Power BI Service (partial cloud lift): When data residency requirements allow, moving specific report collections from PBRS to Power BI Service gains access to monthly feature updates, Copilot, and the improved mobile rendering engine. The migration involves converting .rdl paginated reports to Power BI paginated format (if needed for pixel-perfect layout) or rebuilding as Power BI Desktop reports. The On-Premises Data Gateway bridges remaining on-premises data sources. Publish the migrated workspace to SharePoint via the Power BI web part; the intranet user experience looks identical to the PBRS web part — they see the report embedded in the SharePoint page under the same navigation.

Stage 3 — Full Microsoft Fabric integration (greenfield path): For organizations with new reporting requirements (not SSRS migrations), building directly on Microsoft Fabric — with Lakehouse as the data foundation, dataflows for transformation, and Power BI as the visualization layer — avoids the SSRS technical debt entirely. Fabric's OneLake architecture means a single logical data lake backing all Power BI reports, with SharePoint and Teams tabs as the portal surfaces. This is the recommended starting point for any new intranet BI initiative in a Microsoft 365 environment as of 2026. See our Power BI guide for Fabric integration details and our data governance guide for Fabric's governance model.

Last reviewed and updated: May 8, 2026

Frequently Asked Questions

For a broader look at standalone BI platforms not tied to a portal, see our BI software comparison and best business intelligence tools guides. For the migration path from legacy SSRS-based intranet reporting, our SSRS migration guide covers the full SSRS-to-PBRS-to-Power-BI-Service progression with tooling, timelines, and common failure modes. For governance and data cataloging in large intranet BI deployments, see data governance guide.

Not affiliated with Microsoft, Atlassian, Tableau, or any software vendor listed in this guide. All pricing figures are approximate list prices as of May 2026; confirm current pricing with each vendor before budgeting.