What bursting looks like#

Bursting is one job producing many personalized outputs and delivering each to the right person. Most jobs in Timberline do it, 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.

• Sales Rep Scorecard produces a scorecard per manager because a filter says who the managers are.
• Divisional Packet produces a pack per region because a drill-down says what the regions are.
• Financial Statements produces a statement pack per market because the market list comes from the model, not from a roster somebody keeps.

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 Sales Rep Scorecard, because both replication modes are running at once in a single job.

1. Open the job and look at the parameters. Manager is set to one report per item and resolves to the thirteen people the model says are managers; Rep is one page per item and cascades, so it resolves to this manager's direct reports.
2. Run Test / preview: thirteen outputs, before anything is delivered.
3. Run the job.
4. Open the demo inbox. Thirteen emails, each addressed from MgrEmail in that manager's own copy of the workbook, each PDF containing that manager's team page and a page per rep underneath it.

Nobody typed thirteen names anywhere. Add a manager to the model and the fourteenth email appears on the next run.

A burst that is not a burst#

Board Packet with Division Slides is the useful counter-example. It produces four versions of the market review, but they all land in one deck, as four repeated slide sections, delivered once - where Divisional Packet, built on the same content, gives each region its own file.

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 with Division Slides and Divisional Packet back to back settles it in about ninety seconds.

Bursting at scale#

Thirteen managers is a demo-sized number. The same job unchanged would serve the full 237-person sales organization, because the parameter would simply return more values.

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. Turning combine on - Divisional Packet and Board Packet with Division Slides both have it - groups finished outputs into one message per key. 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