Reference

Glossary

Bricksta uses these terms consistently. A shared vocabulary makes flows understandable across teams.

On this page

The terms on a case

A running case gathers most of the core terms in one place: it is created from a template, is made up of tasks, carries a status and a progress derived from it.

A case in Bricksta with template, status, progress, owner and the tasks it contains
Visible on a case: template, status, progress and the tasks it contains.
Template
The reusable blueprint of a flow: which tasks in which order. The template does not run itself, it describes.
Case
A concrete run of a template with its own status, progress and history. This is where the work happens. In the menu: Cases.
Task
A single step within a case — with an owner, a status and optionally captured fields.
Workflow / Phase
Structuring levels within a template: a workflow is a strand of the flow, a phase a section within it that groups related tasks.
Status
The state of a task or a case. In Bricksta the status is the truth — there is no second, diverging progress.
Progress
Follows deterministically from the status of a case's tasks — not a manually set value.

The terms of the flow

In the template editor you define the order in which work happens and what occurs when something is rejected. Four terms cover this.

Dependency
The rule that says what a step waits for. It always sits on the waiting step, never on the one before it — which is why the editor shows, at each step, what must have happened before it.
Branch
A point where several paths lead away from the same step. If it says “either-or”, exactly one of them is pursued and the others fall away; without that addition all paths run in parallel.
Back-jump
A connection back to an earlier step — for example when an approval is rejected and the rework starts over. A back-jump is not a dependency: it does not say what is waited for, it says where things go back to.
Round
How often the same step has already been worked on within a case. After a back-jump round 2 begins, and what was captured in round 1 stays readable.

Structure: category and process type

Categories and process types structure the process map: process types are the bands, categories sit within them and group templates and cases.

The process map with process-type bands and the categories within them
Visible in the process map: process types as bands, categories as colored cards within them.
Category
An ordering level that groups templates and cases — with a color and an icon, for overview and findability.
Process owner
The person accountable for a category — set under Categories, optional. On the process map they appear as an initials badge on the card and in the panel. Not to be confused with the person responsible for an individual case.
Process type
The functional kind of a flow (classically Leadership, Core, Support). Process types structure the process map as bands.

The terms of a case's analytics

The "Analytics" tab of a case measures the process, not the person. These terms appear there on tiles, rows and cards.

Cycle time
The time from a case's creation to its completion — for a running case "so far", up to today. The reference for norm, forecast and time shares.
Norm
The median cycle time of the last 20 completed cases of the same template, from five completions on. The comparison figure, not the forecast.
Provisional norm
The same calculation over the visible completions when there are fewer than five — with the case count beside it, so nobody takes it for reliable.
Plan cycle time
The sum of task due dates along the longest path of the template, from the snapshot frozen at start. The yardstick where no norm exists yet.
Forecast
The expected completion: today plus the norms of the phases still open along the longest path per workflow. "At the earliest" when a running phase has already used up its norm.
Forecast per phase
An expected start and end for every open phase; on the timeline a dashed box to the right of today.
Waiting time
The time a task was open without anyone working on it — measured per task and summed over all; that is why it can exceed the cycle time.
Blocked time
The time a task was explicitly blocked.
Time outside
The time portal tasks or external approvals lay outside the house — as a sum for the case, never per person. The surface names the participant by their role (Bewerber:in, Lieferant) rather than calling everyone a customer.
Time-share bar
Waiting, blocked and time outside as shares of the elapsed time. Shown only from two distinct workers on, because otherwise the remainder would be one person's working time.
Working span
The time from a task's start to its completion. Deliberately not shown on the case: for one person it would be their performance.
Target effort
An effort stored on the task definition that the working span would be compared with. Not built, because it would be a person figure.
Bottleneck
The running phase furthest past its norm. Listed under "Act now" with a jump to the phase.
Standing
Where a running case's elapsed time stands among the last 20 completions of its template: faster than the median, slower than the median, slower than 90% — fixed reference points, not a rank.
Process deviation
Tasks that were not in the template (ad hoc) or were skipped. Formerly "plan deviation"; renamed so that "plan" is free for the plan cycle time.
Automation share
The share of completed tasks done by an agent or the system — on the case only from two human workers on, the template average regardless.
Act now
The block of action rows: findings, bottleneck, customer, action step, agent — every row names a task or phase and has a jump.