Seamlessly Generating and Downloading SSRS Reports in MFA-Enabled Power Pages Environments - CloudFronts

Seamlessly Generating and Downloading SSRS Reports in MFA-Enabled Power Pages Environments

Generating SSRS (SQL Server Reporting Services) reports from within Power Pages becomes more complex in environments secured by Multi-Factor Authentication (MFA). Traditional approaches that work in basic environments tend to fail silently or inconsistently when MFA, session tokens, or cookie-based auth are involved.

In this blog, I’ll share a real-world solution where a Project-based SSRS report was generated securely, sent via email, and optionally downloaded — all within the constraints of a Power Pages + Power Automate architecture in a Dynamics 365 MFA-protected environment.

Step 1: Pre-Outline Brief

  • Target Audience: Power Platform consultants, Dynamics 365 developers, IT administrators working in secure, MFA-enabled environments.
  • Purpose: To help readers understand how to bypass authentication roadblocks while triggering SSRS reports through Power Pages portals.

Pain Points Solved:

  • -SSRS authentication in MFA environments
  • -302 redirects or session expiration when calling report endpoints from Power Automate
  • -Need for dynamic, secure user-facing report delivery

Step 2: Core Content

Scenario Overview

  • -The SSRS report is embedded within a Dynamics 365 instance.
  • -End users trigger report generation by selecting a Project ID in Power Pages.
  • -Power Automate handles the report generation.
  • -Users receive the report via email.

Problem Statement

Standard HTTP-based retrieval of SSRS reports using the Reserved.ReportViewerWebControl.axd endpoint fails in MFA-protected environments due to missing browser session cookies. This often results in 302 redirects or HTML-based error messages that cannot be processed by Power Automate.

Initial Approach and Issue

A flow was constructed to:

The Project ID is captured from Power Pages and passed to a Power Automate flow using an HTTP trigger, which is initiated when a user clicks a button on the portal—triggered via embedded JavaScript.

Build the SSRS report URL dynamically.

Compose -> PDF Download Start – Index ->

add(indexOf(outputs('Invoke_an_HTTP_request')?['body'],'"PdfDownloadUrl":"'),18)

Compose -> PDF Download String Length ->

sub(indexOf(outputs('Invoke_an_HTTP_request')?['body'],'","PdfPreviewUrl"'),outputs('PDF_Download_Start_-_Index'))

Compose -> PDF Download URL -> (Replaced the PrintOnOpen=true parameter with PrintOnOpen=false in the report export URL to prevent the print dialog from automatically appearing when the PDF is opened)

replace(
  replace(
    substring(outputs('Invoke_an_HTTP_request')?['body'],
             outputs('PDF_Download_Start_-_Index'),
             outputs('PDF_Download_String_Length')),
    '\u0026',
    '&'),
  'rc:PrintOnOpen=true',
  'rc:PrintOnOpen=false')

Perform an HTTP GET request to download the report.

This failed consistently on the first try due to the report session page not being fully ready or authenticated, especially in an MFA environment.

Working Solution: Retry with Delay in Power Automate

To overcome the session-based delay, we implemented a retry pattern inside Power Automate:

  • -Added a Delay action before calling the HTTP step.
  • -Enabled Retry Policy on the HTTP action that invokes the SSRS report.
  • -Set retry count to 3 with exponential backoff.

Outcome:

The flow fails the first time (as expected), but succeeds on the second or third retry as the session becomes valid and the SSRS report is available.

Power Automate Configuration Highlights:

  • Delay Action: Inserted a delay of 10 seconds before the HTTP request to allow Dynamics to establish a valid report session.

Added a Scope block after the first HTTP request and set the Configure run after to Skipped and Failed

If needed, you can add the third delay if the second one fails.

  • HTTP Action Retry Settings: – You can also try this
    • Retry Policy: Enabled
    • Count: 3
    • Interval: Default exponential backoff
  • Error Handling: Even if the first request fails, the subsequent retries succeed in fetching the report.

Benefits of This Approach:

  • -No JavaScript or browser session dependency required.
  • -All logic remains within Power Automate and Power Pages.
  • -Compatible with MFA-protected environments.
  • -Fully automated email delivery of the PDF.

To conclude, sometimes, achieving reliability in secure environments isn’t about complex code—it’s about using the right orchestration patterns. By strategically delaying and retrying the HTTP request to SSRS within Power Automate, we achieved consistent, secure report generation that works even under MFA constraints.

🔗 Need help implementing this retry-based flow in your environment?Reach out to CloudFronts—we help businesses implement scalable, reliable solutions every day. You can contact us directly at transform@cloudfronts.com.


Share Story :

SEARCH BLOGS :

FOLLOW CLOUDFRONTS BLOG :


Secured By miniOrange