What bursting is and when you need it#
Bursting is the outcome of one report producing many personalized outputs: a P&L per cost center, an expense report per department, a statutory pack per legal entity. You build one source template, and Reportworq produces and delivers the whole set.
There are two different mechanisms that produce that outcome, and confusing them is the single biggest source of wasted effort in this part of the product.
Three words, kept straight#
| Term | What it means |
|---|---|
| Bursting | The outcome. One report, many outputs. It is a result, not a screen. |
| Replication | A parameter that holds more than one value fans the output out, one output per value. You set the parameter's replication mode on the Parameters step and you are done. The Bursting step is not involved at all. |
| Burst set | One row on the Bursting step. Each row carries its own value for each burst parameter and, optionally, a recipient. The Bursting step is hidden until a parameter is flagged Burstable. |
Throughout the guides, output fanned out by a parameter's own values is called replication, and burst set always means the Bursting-step feature.
The distinction people miss: the Burstable flag is not what makes output multiply. A parameter that already holds several values and has a replication mode is producing many outputs whether or not it is flagged Burstable. The flag does exactly one thing: it unlocks the Bursting step. If you are not building burst sets, leave it off.
Which one you need#
Use replication when:
- The values you want to fan out on already exist somewhere you can read them, such as a Planning Analytics subset or MDX query, a SQL query, a Workday Adaptive dimension, an Excel range, or a typed Text List.
- Every output is built the same way and differs only by that value.
- The list should stay current on its own as the business changes, with no second list to maintain.
This is the common case, and it is where most jobs should land. See Replicate output from your source system.
Use burst sets when:
- You need per-output control: a different value, a different query, or a different recipient for individual outputs rather than the same treatment for every one.
- You have a fixed, curated list with no home in a source system, such as a roster of stores or an external distribution list.
- The list of outputs is easiest to maintain as a spreadsheet or a standalone query that the business already keeps.
See Burst sets.
What a burst set adds#
A burst set is worth the extra step when the outputs are not all built the same way. The Bursting grid gives you one row per output and one column per burst parameter, so each output can carry its own values.
The part that saves the most work is the default. Every cell starts by inheriting the value already set on the Parameters step, and it shows as Default with that value. You only edit the cells that need to differ, which become overrides.
That matters most when a burst parameter is query-driven. If the parameter is a Planning Analytics MDX query or a SQL query, the query you enter once on the Parameters step is the default across every burst set. A grid of 30 sets needs that query entered once, and you override only the two or three sets that need a different query or a fixed value. At run time each set applies only the values it actually carries, and every cell left at Default falls through to the job parameter.
How the two fit together#
Replication and burst sets are separate axes, and a job can use both.
- Replication is set per parameter with its replication mode. One report per item produces a separate output file per value. One page per item produces extra worksheets inside one output instead of more files. No replication declares that the parameter is a single value.
- Burst sets sit outside that. Reportworq works through the burst sets first, applies each set's values on top of the job's parameters, and then replicates within that set. A job with four burst sets whose parameters do not replicate produces four outputs. If a parameter still replicates inside each set, each set produces one output per value.
- When no burst sets exist, the job behaves as a single implicit set, which is why replication works perfectly well on a job that never opens the Bursting step.
Recipients are optional#
Neither mechanism requires you to name a recipient. An output that has no recipient is still produced and still delivered, using the job's own destinations, such as a fixed network folder or a static email list.
When outputs do need to reach different people, the recipient can come from several places: an attribute alongside the value in your source system, a value on a worksheet in the report, a Contact column in an Excel or SQL burst source, or a contact picked by hand on a burst set. The address book is one convenient way to hold that information, not the required one. See Assign recipients to bursts.
What each path needs#
- Both paths need at least one parameter on the job. A parameterized report is the prerequisite for every form of bursting. See Parameterize a report.
- For replication, the parameter's type can hold more than one value. See Parameters reference for the full type catalog and the replication modes.
- For burst sets, decide where the list of sets will come from: the grid, a workbook, or a query.
Going deeper. A parameter can reference another parameter's value inside its own query and repeat that query per item, which produces cascading one-report-per-item fan-out. See Advanced parameters.
Feedback on this page
Comments, questions, requests, or something missing or unclear? Email us - the page you are on is filled in for you.
Email feedback on this pageOr write to support@reportworq.com directly.