What bursting looks like#

Bursting is one job producing many personalized outputs and delivering each to the right person. Timberline does it eight times over, and it is worth being precise about how, because the mechanism is the thing customers get wrong.

The headline: Timberline has no burst lists#

Open any Timberline job and look at the bursting screen. There is nothing in it.

Every job here fans out from its parameters, driven by the planning model, not from a burst set someone typed in. That is deliberate, and it is the single most useful thing to show, because the assumption most people arrive with is that bursting means maintaining a list of who gets what.

• Commission Statements produces a statement per rep because RepID has values.
• Sales Rep Scorecard produces a scorecard per manager because an MDX filter says who the managers are.
• Divisional Packet produces a pack per region because an MDX drill-down says what the regions are.

Nobody maintains any of those lists. They are the model's lists.

Burst sets still have their place (a curated external roster with no home in a source system), but Timberline deliberately does not use one, so the demo does not teach the wrong habit.

Where the recipient comes from#

The second half of bursting is routing: which output goes to whom. Timberline answers that from the workbook, not from a contact list.

Each source workbook contains a named range whose formula chains through the planning model's element attributes: it reads the VP code attribute of the current Market, then reads the Email attribute of that person, one lookup nested inside the other.

Read outward: take the market, look up its VP code, look up that person's email. The job's Email to field points at that named range, so each burst addresses itself.

The consequence is worth saying in a demo: the distribution list is maintained in the planning system, by the people who already maintain the org chart. When someone changes role, the next run is already correct.

Watching a burst happen#

The cleanest demonstration in the workspace is Commission Statements, because you can see the fan-out and the roll-up in the same run.

1. Open the job and look at the parameters: RepID has nine values, so nine statements.
2. Run Test / preview, you see the nine outputs before anything is delivered.
3. Run the job.
4. Open the demo inbox. There are not nine emails. There are a handful, one per manager, each containing that manager's whole team's statements.

That last step is the combine key doing its work: the job groups the burst outputs by a Territory cell value before sending.

A burst that is not a burst#

Board Packet with Division Slides is the useful counter-example. It also produces four versions of the market review, but they all land in one deck, as four repeated slide sections, delivered once.

That is the distinction between the two replication modes:

• one report per item → many files, many deliveries, a burst
• one page per item → one file, one delivery, repeated content inside it

People conflate the two constantly. Running Board Packet and Board Packet with Division Slides back to back settles it in about ninety seconds.

Bursting at scale#

Commission Statements is configured with nine reps, which is a demo-sized number. The underlying design supports the full 237-person sales organization, the parameter would simply return more values, and the combine key would still roll them up per manager.

Two things to size before scaling a burst like this for real:

• Output count multiplies with cascading parameters. One report per manager times one page per rep is fine; one report per rep times one page per period times one page per product is not.
• Combine changes the delivery count, not the generation count. The job still generates every output; combine only affects how many messages leave.

Related#

• How parameters work
• Customer guide: What bursting is and when you need it