Yes. SQL Server Reporting Services can burst reports natively using data-driven subscriptions, and for a lot of common jobs, invoices, regional sales summaries, per-client statements, that native capability is all you need. Where it runs out of road is packaging multiple reports together, handling retries when a delivery fails, or scaling past a few hundred recipients without babysitting the job.
Here's where to start:
- Confirm your report has a burst key (a field like
CustomerIDorRegionCodethat defines how output gets split) - Build a delivery control table before you touch the subscription wizard
- Decide now whether you need packaging or retry logic, because that decision determines whether SSRS alone will get you to the finish line
Key Takeaways
SSRS handles straightforward report bursting through data-driven subscriptions, but packaging, retries, and high-volume delivery require either custom scripting or a dedicated automation layer.
| Point | Details |
|---|---|
| Native bursting works for simple cases | Data-driven subscriptions split and deliver reports per recipient without extra licensing on Standard or Enterprise editions. |
| Report design comes first | Add a burst key, group headers with page breaks, and parameterize the query before configuring any subscription. |
| Delivery table drives everything | Build a control table with KEY, OUTPUT_FORMAT, DEL_CHANNEL, and recipient columns as the subscription's data source. |
| Test small before scaling | Prototype with 5 to 10 recipients to catch parameter and formatting issues before running the full list. |
| Automation products fill the gaps | ChristianSteven Software's PBRS adds packaging, REST API delivery, and SOC 2 Type II backed audit trails that native SSRS subscriptions don't offer. |
Table of Contents
- What SSRS Report Bursting Actually Does
- Standard Subscriptions vs. Data-Driven Subscriptions: What SSRS Can and Cannot Do
- Getting the Report Ready for Bursting
- Setting Up Data-Driven Subscriptions Step by Step
- Formatting and Delivery: What Changes by Output Type
- Scaling Bursting Runs Without Breaking Them
- When an Automation Product Beats DIY Scripting
- What I'd Tell a Team Starting This Tomorrow
- Get SSRS Bursting Running Without the Custom Scripts
- Sources
- FAQ
What SSRS Report Bursting Actually Does
Report bursting takes one report execution, splits the output by a key value, and delivers each personalized slice to a different destination. One dataset, dozens or hundreds of outputs, no manual copy-pasting.
Two concepts drive every bursting setup:
- Split By determines how the data gets divided (by customer, region, department, whatever key makes sense for the business)
- Deliver By determines where each split lands (a specific email address, a folder path, a cloud bucket)
Finance teams use this for monthly invoices. Sales ops uses it for territory-specific pipeline reports. HR uses it for individual manager dashboards. The delivery channel is usually email, but file shares and cloud storage folders work just as well when recipients pull reports rather than receive them.
Standard Subscriptions vs. Data-Driven Subscriptions: What SSRS Can and Cannot Do
SSRS ships with two subscription models, and confusing them wastes a lot of setup time.
- Standard subscriptions send one report to one fixed recipient list on a schedule. No personalization, no per-recipient filtering. Fine for a static weekly summary; useless for bursting.
- Data-driven subscriptions (DDS) pull recipient and parameter data from a query at runtime, then render and deliver a separate copy of the report for each row. This is the native bursting mechanism, and it's built into SSRS without extra licensing on editions that support it.
- DDS limits worth knowing before you commit. Data-driven subscriptions require Standard or Enterprise editions of SQL Server, not Express. Recipient lists in the thousands can slow subscription processing to a crawl because SSRS renders each output sequentially rather than in parallel. Excel exports sometimes split a single report into multiple worksheets in unpredictable ways depending on how tablix regions are grouped, which trips up automated post-processing scripts that expect one sheet per file.
Community troubleshooting threads back this up: SSRS users regularly hit multi-file Excel export problems and solve them with a delivery table paired with a data-driven subscription, or by looping execution through SSIS when DDS alone can't handle the formatting demands.
Getting the Report Ready for Bursting
Before any subscription setup, the report itself needs structural changes. Skip this step and no amount of subscription configuration will fix it.
- Add a dedicated burst key field to the dataset (a customer ID, region code, or department name) that every row can be grouped on
- Set a group header on that field and force a page break at the start of each group so each recipient's data renders on its own page or set of pages
- Parameterize the underlying query so the report can execute filtered to a single key value at a time
- Build a delivery control table with columns for KEY, OUTPUT_FORMAT, DEL_CHANNEL, recipient address, and optionally a template ID or locale for regional formatting
- Base the report dataset on a stored procedure or view rather than an inline query, since practitioners consistently recommend this for predictable execution when parameters change per run
Pro Tip: Build the delivery control table as a real database table, not a spreadsheet import. SSRS data-driven subscriptions query it directly at runtime, and a live table lets you add or remove recipients without touching the subscription itself.
Setting Up Data-Driven Subscriptions Step by Step
Here's the practical sequence for standing up a working DDS pipeline:
- Write the delivery query first. This single query, run against your control table, returns every column the subscription needs: recipient email, output format, delivery folder, and any report parameter values. Oracle's bursting documentation describes this same pattern of a delivery definition consuming split and deliver metadata, and the logic transfers directly to SSRS.
- Map delivery columns to subscription settings. KEY drives which data block gets pulled for that iteration. OUTPUT_FORMAT sets PDF, Excel, or Word. DEL_CHANNEL routes to email, file share, or SharePoint. Extra columns, PARAMETER1 through PARAMETER n, map straight to report parameters if your report needs more than one filter.
- Configure the subscription in Report Manager, pointing it at the delivery query and matching each column to the corresponding subscription field.
- Test against 5 to 10 rows first, not the full recipient table. Verify formats render correctly, file names don't collide, and permissions on target folders actually work before scaling up.
That small-batch testing habit isn't just caution for its own sake. Practitioners who prototype data-driven subscriptions at small scale before automating fully tend to surface parameter mapping errors and formatting quirks while the blast radius is still five recipients, not five hundred.
When DDS isn't enough, the fallback is scripting. SSIS packages or PowerShell scripts that loop through a recipient table and call the ReportServer web service directly give you control over retries, packaging multiple reports into one email, and error handling that native SSRS subscriptions simply don't expose. Pick DDS when delivery is straightforward, one report, one format, one channel per recipient. Pick scripted automation or a dedicated tool when you need packaging, retry logic, or destinations beyond email and file shares.
Formatting and Delivery: What Changes by Output Type
PDF and Excel behave differently once bursting is in play, and the differences catch people off guard.
- PDF renders as one self-contained file per recipient, which makes it the safer default for anything going to an external client
- Excel exports can split into multiple worksheets depending on how your tablix is grouped, so test this specifically if a downstream script expects a single sheet
- Use the burst key plus a date stamp in your filename pattern (
Invoice_CustID_20260315.pdf), never a generic name that overwrites on the next run - Email attachments have size limits on most mail servers, so for large PDFs or workbooks, deliver a link to a file share or cloud folder instead of attaching the file directly
- Locale settings affect number and date formatting in Excel exports, worth checking explicitly if your recipient list spans multiple countries
Scaling Bursting Runs Without Breaking Them
Rendering hundreds of reports one at a time strains the report server, and the failure modes are predictable once you've seen them.
- Favor a single run-once execution with a delivery table over rendering the report separately for each recipient, when your platform supports it, since one execution plus a delivery mapping puts far less load on the server than hundreds of individual renders
- Batch large recipient lists into smaller groups and stagger their schedules across a window rather than firing everything at once
- Watch render thread counts and server memory during large runs; this is usually where timeouts originate
- Log every delivery attempt with a timestamp and status so you have an audit trail when someone asks why a report didn't arrive
- Build retry logic for transient failures like a locked file share or a momentary network drop, rather than letting one failed delivery kill the whole batch
Pro Tip: Missing rows in the delivery table are the single most common cause of "some recipients didn't get their report." Before troubleshooting permissions or timeouts, check the control table for gaps first.
Most bursting failures trace back to one of three things: a missing or malformed row in the delivery table, insufficient permissions on the destination folder or mailbox, or a timeout caused by rendering too many reports in one pass. Check those three in order before assuming something more exotic is wrong.
When an Automation Product Beats DIY Scripting
Native SSRS subscriptions and SSIS loops cover a lot of ground, but they stop being the pragmatic choice once you need packaging, retries, REST API triggers, or delivery to destinations SSRS was never built to reach.
- If bursting output needs to reach Slack, Teams, SharePoint, or a database table alongside email, you're building custom connectors that a dedicated tool already ships with
- If you need multiple reports collated into a single package per recipient, that's native functionality in PBRS's data-driven packages, not something DDS does out of the box
- ChristianSteven Software has built BI automation tools for more than two decades, holds SOC 2 Type II certification, and covers SSRS, Power BI, Tableau, and Crystal Reports under one roof, which matters when audit trails and delivery security aren't optional
What I'd Tell a Team Starting This Tomorrow
Start small. Build a data-driven subscription against 5 to 10 recipients before you touch the full list, and check the actual output files, not just the subscription status log, because SSRS will happily report "success" on a delivery that landed a blank PDF.
Run through this before calling it production-ready: burst key added to the dataset, delivery table populated and double-checked for gaps, output formats verified for every recipient type, job monitoring in place, and retry rules defined for the failures you can predict.
If that pilot surfaces gaps around packaging, retries, or delivery scale, that's your signal to evaluate data-driven subscription deployment patterns more deeply, or to pilot a dedicated automation product next rather than layering more scripts on top of SSIS.
— Christian Ofori-Boateng
Get SSRS Bursting Running Without the Custom Scripts
Native data-driven subscriptions handle a lot, but the moment you need packaged multi-report deliveries, retry logic, or destinations beyond email and a file share, PBRS from ChristianSteven Software picks up exactly where SSRS leaves off. It runs data-driven schedules, collates multiple reports into a single package per recipient, and routes output to email, cloud storage, or collaboration tools through a REST API, all backed by SOC 2 Type II certification and two decades of BI automation work across SSRS, Power BI, Tableau, and Crystal Reports environments.
If your team is already stretching SSIS scripts to cover gaps DDS can't fill, that's usually the sign it's time to stop patching and automate the whole pipeline. You can see how PBRS handles data-driven exports and packaging directly, and request a trial to test it against your own delivery table before committing to anything.
Sources
- Report Bursting — Logi Report Designer user guide
- About bursting — Oracle documentation
- SSRS to Multiple Excel Files — Spiceworks Community
FAQ
What Is Report Bursting?
Report bursting is the process of running one report a single time, splitting its output by a key value like customer or region, and delivering each personalized piece to a different recipient or destination.
Is SSRS Being Phased Out?
Microsoft continues to support SSRS as part of SQL Server Reporting Services, and it remains widely deployed, though Microsoft has been steering new investment toward Power BI Report Server and Power BI itself for newer reporting scenarios.
What Is Data Bursting?
Data bursting is another term for report bursting: splitting a single data set by a key value and applying a specific output format and delivery method to each resulting block, a pattern documented across BI platforms beyond just SSRS.
What Do You Do if SSRS Suddenly Takes Longer to Run?
Check for a growing recipient list overloading sequential rendering, missing indexes on the underlying query, or a spike in concurrent subscriptions competing for render threads, and consider batching large runs or moving to a delivery table with run-once execution to reduce server load.