02a - Panel anatomy: tabs, sections, rows, and components

Info: This article is work in progress and subject to change.

Every Workflow Assistant panel is built from the same four nested pieces: tabs, sections, rows, and components. Once you can name the four pieces in any panel you look at, the Configurator interface, the Lucene conditions, and the visibility rules in this manual all read as one consistent system.

This article describes each of the four levels in turn, shows how they nest, and ends with a small Quick Start that lets you spot them in an example panel.

If you only read one concepts page in this manual, read this one.

Annotated Workflow Assistant panel showing “Tab”, “Section”, “Row”, and “Component”

The four levels at a glance

Each tab contains one or more sections; each section contains one or more rows; each row contains one or more components.

The four levels in detail

Tabs

A tab is the top-level container for everything a particular audience sees in the panel. Most panels have several tabs because the same panel often serves more than one role: an editor tab for content reviewers, a production tab for operators, a status tab for managers.

The two things you set on a tab are:

• Display name — what users see at the top of the panel
• Audience — which Assets user groups see the tab. Set this to All if every user with the panel role should see the tab, or to one or more named groups if the tab is for a subset

Note: A user with no matching group simply does not see the tab. There is no warning, no error, and no empty state — the tab is rendered as if it were not there. This makes audience targeting safe but also makes a misconfigured group mapping invisible. The “Tabs and audience targeting” page covers how to test this.

Sections

A section sits inside a tab and groups related rows together. Each section has a label (the heading users see) and a description (a short sentence explaining what the section is for).

Sections do real work. They:

• Make a long tab scannable
• Explain the purpose of each group of fields and actions
• Establish your house terminology (use the same labels users hear elsewhere in your organisation, not the technical names from your Assets schema)
• Allow you to apply visibility and disabling rules to a related cluster of components, instead of repeating the same rule on each one

A typical tab has between two and six sections. More than that and the tab is doing too much; consider splitting it.

Rows

A row is a horizontal arrangement inside a section. Most rows hold a single component — one field, or one button, on its own line. When you need two or three components side by side (think a Width / Height pair, or an Approve / Reject pair), you place them in a multi-column row.

Three layout types are available:

You can also drop a Divider in place of a row to separate visually distinct parts of a section.

Tip: Avoid two- and three-column rows for long fields like Rich text or wide Dropdowns. They look cramped, push labels onto a second line, and force users into horizontal scanning that single-column layouts handle better.

Components

The component is the unit of functionality the user actually interacts with. There are three types, called entity types in the Configurator — see the next page (Component types) for what each one is for.

Every component has its own configuration: which asset kinds it applies to, whether it is required, whether it is disabled, what hint text appears, and so on. The depth of options is the reason the Configurator earns its keep. The Reference section of this manual (section 05) covers every option on every type.

How the four levels nest

It is worth seeing the structure on one screen, because the rest of the manual depends on it:

Panel
└── Tab "Brief reference"               (audience: All)
    ├── Section "Brief details"
    │   ├── Row (Grid x1) — Text field "ISBN"
    │   ├── Row (Grid x1) — Text field "Product code"
    │   └── Row (Grid x3) — Text field "Page" + Text field "Position" + Text field "Unit"
    ├── Section "Find related briefs"
    │   ├── Row (Grid x1) — Query button "Show all briefs with same ISBN"
    │   └── Row (Grid x1) — Query button "Show all briefs with same Product code"
    └── Section "Status"
        └── Row (Grid x1) — Notification "Awaiting approval"
Tab "Approval"                          (audience: Reviewers)
    └── Section "Take a decision"
        └── Row (Grid x2) — Approve button + Reject button

The same configuration in the Configurator interface is built top-down: you create a tab, then a section, then add a row of the layout you want, then drag components into the row.

Quick Start: name the four levels in this example

The fastest way to internalise the structure is to identify each level in a real panel. Open any existing Workflow Assistant configuration — your own, or a colleague’s — and work through the steps below.

Step 1. Find the tabs. Look at the very top of the panel. How many tabs does the panel have, and what audience does each one serve? If you only see one, that is fine — many simple panels have a single tab.

Step 2. Pick a tab and find the sections inside it. Each one has a labelled heading and a short description below the heading. Count them.

Step 3. Inside one section, find the rows. A row is a horizontal slice. A single full-width field is a row. Two fields side by side are a row. A three-up reference like Dimensions / Size / Duration is a row.

Step 4. Inside one row, find the components. A component is a single field, action, or notification. Note which one is which — you will see at least one Field, often an Action, and ideally a Notification giving feedback.

Step 5. Open the Configurator and rebuild the structure of that tab in your head: tab → sections → rows → components. Once you can do that without looking, you are ready for the rest of the manual.

Tip: Keep one example panel open in a second browser tab while you read the rest of the Concepts pages. Cross-referencing what the manual says with what you can see in a real panel speeds up everything that follows.

What about containers and grids

You will see the word container in the Configurator’s JSON if you ever look at it directly. A container is the technical term for a row that wraps one or more components. You do not configure containers explicitly — they appear automatically when you create a row. Mention them only when reading raw configuration files or talking to support.

The same applies to the special section type values in the JSON, such as grid, that the Configurator generates when you choose a multi-column row layout. Stick to the visual configuration in the Configurator and the Reference pages; the JSON is there if you need it for a power-user case.

Where to go from here

• 02b - Component types: Fields, Actions, and Notifications — covers what fits inside a row and what each type is for
• 02c - Asset kinds and visibility — covers how each component decides whether to appear for the assets the user has selected
• 02d - How conditions work: Lucene and regex in plain language — covers the two query languages that drive disabling, requirement, and notification visibility
• 03c - Your first panel — a Quick Start tutorial — once the concepts pages are clear, build a tiny working panel end-to-end

Revisions

• 7 May 2026: First publication of the manual