> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dash360.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Building Blocks
> Blocks are the review slide elements that are not reports: KPI tiles, a percent complete gauge, a status list, a next milestone card, and a key milestones table.
# Building Blocks
A report is a chart or a grid over your project data. Some of the things a review slide needs are neither: a row of KPI tiles, a progress ring, a table of the milestones that matter. Those are **blocks**, and you build them in Report Studio alongside your reports.
This page is part of the [Report Studio](/user-guide/reporting/report-designer) guide.
## What makes something a block
The dividing line is simple. If what you want can be expressed as a chart or a grid over one data source, build a report. If it cannot, build a block.
Blocks share three things that reports do not:
* **A block carries no project and no period.** Whatever places it supplies those: a dashboard supplies the filters at the top of the page, a deck supplies the slide's own group. That is why one block can serve a project slide and each of its child slides without being copied.
* **A block resolves everything on the server.** The number, the wording, the color and the columns are all decided once, so the same block cannot read one way on a dashboard and another way on a slide.
* **A block has a scope, not a filter set.** A scope is a project, a reporting period, and a place in the WBS (optionally narrowed to a work package or a control account manager).
## Creating a block
From the Report Studio landing page, choose **New**, then **Block**. Pick the type. The type is fixed at creation, exactly like a report's, because it decides the shape of what gets saved.
Every block's editor has the same two halves: the configuration on the left, and a live preview on the right.
The project, period and group selectors above the preview are **preview context**. They are not saved with the block. They exist so you can see what the block does at a scope you recognize; a block that saved them would show one project's numbers to everybody.
## Scope: inherited or pinned
Every block asks the same question near the top of its configuration:
* **Whatever the surface is showing** (the default): the block reads the dashboard's filters or the slide's group. This is what you want almost always.
* **A scope of its own**: the block always reads the WBS you name, whatever the page around it is showing. Useful for a slide that has to carry one fixed comparison alongside changing content.
A pinned block ignores the surface entirely, so the preview's group box is disabled when you pin one.
## Bands: how a block decides what is good
Four of the five block types color something, and they all use the same band model, so a red tile and a red row on the same slide mean the same thing.
A band is a range, a status, a color and a short reading. Bands are matched **first win** in the order they are listed, most favourable first, which is how neighbouring bands share an edge without either one having to know about the other.
The four statuses are **Favorable**, **Watch**, **Adverse** and **Neutral**. Neutral is what a block takes when there is nothing to judge, and that is deliberate: a milestone with no baseline has neither met nor missed anything, and painting it green would be a claim the data does not support.
Leave the bands alone and you get the shipped set for whatever the block is measuring. Those defaults are sensible starting points, not house policy.
## Scoreboard
A row of KPI tiles. Each tile names a measure, takes its value at the block's scope, and colors itself through the bands.
Use it for the headline numbers a review opens with: budget at completion, budget remaining, schedule variance, cost variance, SPI, CPI.
Money tiles deliberately carry no band. A budget is not good or bad, it is just large, and coloring it invites a reader to draw a conclusion from a number that does not support one.
## Percent complete gauge
A ring showing progress, with a marker on the arc for where the plan says you should be, colored by a third measure.
It states two numbers at once and is judged by a third, which is why it is not a round scoreboard tile. The reading comes from the gap between where the ring reaches and where the marker sits.
By default the ring is earned percent, the marker is planned percent, and the color comes from SPI.
## Status list
A WBS rollup as horizontal bars, one row per child of the scope. It is the gauge repeated for every child, and reads through the same fields.
Two settings decide whether a truncated list is worth reading:
* **Order by** puts the rows in an order. Worst performing first is what a review meeting usually wants at the top.
* **Most rows** caps the list. Whatever is cut is always counted and said out loud beneath the list, so a strip showing ten of forty never reads as a complete list of ten.
Leave **Show the band value** on. Color needs a bar to appear on, and a child at zero percent earned draws no bar at all, so the worst performer on a project can render as an empty track that looks exactly like one that has simply not started. Printing the index tells them apart where the color cannot.
## Next milestone
A card naming the next milestone due in the scope, with its date, how far it has moved, and how much room it has left.
### Which milestone counts
The card takes the earliest finishing milestone still open in the scope. If you name one or more **levels**, only milestones at those levels qualify.
Leave the levels box empty unless you know your project states them. Most projects do not, and a card that requires a level renders empty on those projects and looks broken rather than unconfigured. Clear the box, look at the preview, and the badge on the card tells you what this project actually uses.
A milestone's level comes from the **Milestone Level** field when your schedule sets it. When it does not, Dash360 reads a marker in the activity name, written as `(D1)`. The parentheses matter: an activity called "Scalability on Horizon (MuST) D4" is not a D4 milestone.
### Slip and float say different things
The card prints both, and it colors by whichever one you choose under **Color by**.
* **Slip** is how far the milestone has moved from its baseline. It is the reading most review slides are held about.
* **Float** is how many days it can still slip before the **project's** finish date moves. Zero float means it sits on the critical path; negative float means the network as scheduled already cannot deliver it on time.
They routinely disagree, and each decides whether the other matters. A milestone can be months late with months of slack, which has slipped badly and threatens nothing. Another can be exactly on plan with no float at all, where a single day's slip moves the whole project. Color by slip and the first goes red while the second goes green.
Choose the basis that matches the question your slide is asking, and note that the card says which one it used.
### Overdue is measured against the reporting period
Not against today. A deck built in August for a June period says what was overdue in June, which is the only way a deck of a past period can be read honestly.
## Key milestones
A table of the headline milestones in the scope: level, WBS, milestone, finish date and percent complete.
This is the schedule panel of a project review slide. Where the next milestone card answers "what is next", this answers "where do the headline milestones stand".
### Ordered by level, then by date
By default the table sorts by level first and by date within each level, which is what puts the most senior milestones at the top of the slide.
This is worth understanding because it explains something that otherwise looks inconsistent. A project has enough high level milestones to fill a table on its own, so a dozen rows on the project slide may not get past D1. The same block on a child slide has fewer milestones at each level to work through, so the same dozen rows reach much further down. One configuration, two slides that look different for a good reason.
Switch **Order by** to date alone when the question is "what is coming next" rather than "what are the headline milestones".
### The WBS column appears when it earns its place
Left on **Auto**, the table carries a WBS column when the block reads the whole project, and drops it when the block is scoped to a WBS.
A slide titled "WBS 1.02 Scientific Computing Systems" does not need a column repeating 1.02 a dozen times. Width is the scarcest thing on a review slide, and that column would spend it on something the reader has already read. Clear the group box above the preview and you will see the column come back.
The codes print one level below the scope, so a milestone whose full WBS is 1.02.02.08 shows as 1.02 on the project slide. What the reader is being told is which child of the scope it belongs to.
### Completed milestones stay in
Unlike the next milestone card, this table includes milestones already delivered, and that is on by default. A delivered D0 is the best news on the slide. Hiding it would make a project that is going well look like a project with fewer milestones.
### A card when there is only one
Left on **Auto**, the block draws a table when several milestones qualify and a card when exactly one does.
A table of one row is not a small table. Every row gets the same height, so a panel sized for a dozen milestones and given one renders an enormous header above one enormous row. The card is what that panel should look like.
If your deck needs a panel that keeps its shape every period whatever the schedule does, set **Shape** to **Always a table**.
### Fitting the table
**Most rows** is how you make the panel fit. Twelve rows sit comfortably beside a chart. Whatever is left out is always counted and stated beneath the table, so twelve of a hundred and eighty-three never reads as a complete list of twelve.
Milestone names are never abbreviated. A truncated name produces rows a reader cannot tell apart, three of them reading "CPU Partition..." one after another, so the name wraps in a wide column instead and the row cap is what controls the height.
Slip, float and owner columns are off by default. A dozen rows of "59 days late" beside a dozen dates is a wall of text in the narrowest panel on the slide. Turn them on when the block has the width to carry them.
## Dates on a block
Two of the block types print dates, and each has a **Date format** box that takes a standard format pattern such as `M/d/yyyy` or `d MMM yyyy`.
The two blocks ship with different defaults on purpose. The next milestone card uses `d MMM yyyy`, which reads the same on both sides of the Atlantic where a slash format does not. The key milestones table uses a slash format, because it was built to reproduce a review deck that prints dates that way.
If you put both blocks on one slide, set one of them so the two agree.
## Where blocks appear
A saved block can be placed on a **dashboard**, as a tile alongside report tiles, and in a **deck**, as a slide element.
In a deck, a block renders as native PowerPoint content, not as a picture. A key milestones block becomes a real table, so whoever finishes the deck before the meeting can retype a date or drop a row without regenerating anything.