The Page Designer & Widget Library

Dashboards and other widget pages are assembled, not programmed. Two screens do it: a library of reusable widgets, and a designer that places them on a page. Nothing here needs a deployment — a page shows your change the next time it loads.

Where to find it

Both need permission to view widgets; saving needs permission to manage them.

The library: define once, place anywhere

A library widget holds the definition — its kind, where its data comes from, and its default display options. Pages then place it. The point of that split is in the library's own words: editing a widget updates every page that uses it.

The list shows each widget with its Kind, its Binding (what data it reads) and its Origin — Global (shared by every space) or This space. A space definition shadows a global one with the same key, so a space can replace a shared widget without touching it. Widgets the system ships are protected.

Creating and editing a widget happens in the full-page widget builder. This page keeps the list and the delete button.

Deleting is guarded. If any page still places the widget, the delete is refused and the refusal lists the pages. You then have a choice: go and remove those placements, or press Remove everywhere — a stronger confirmation that deletes the widget and every placement of it.

The designer: placing widgets on a page

Pick a page from Pick a page… and you see its effective widget set — what the page actually renders, after the layers below have been resolved.

Layers

A widget page is resolved from layers, and you choose which layer you are editing:

• Just me — a personal dashboard. Only you see it.
• Space — everyone in the space sees it, unless they have a personal layer of their own.
• Global — every space (super-admin only).

Each row in the table shows its Effective layer, so you can always see whether what you are looking at is yours, the space's, or the system's. Remove override deletes the row at this layer; the widget then falls back to the layer beneath it rather than disappearing.

Placing one

Press + Place widget. The palette offers two things: a widget from the library, or a new one by kind (which is added to the library as well). Then configure it.

Grid position

Widgets sit on a 12-column grid:

If two widgets would sit on top of each other, the designer says so — it names the widget you overlap rather than silently rearranging the page.

Page settings: how rows behave

Page settings… controls the whole page's row behaviour:

• Uniform rows — every widget aligns to proportional rows, so a 2-row widget is exactly two-thirds the height of a 3-row neighbour. Content scrolls inside its share.
• Minimum row height — a floor in pixels, not a fixed size: rows still grow with their content.
• Maximum row height — a ceiling in pixels; a capped row scrolls its content. Empty or 0 means no limit. It has no effect when uniform rows are on, because those pin to the minimum.
• Force height on a single widget — that widget always fills exactly that many rows, content scrolling inside, and widgets sharing its rows stay proportionally aligned.

Who sees a widget

Each placement has an optional Visibility section with two independent conditions:

• Required role(s) — the contact whose record the page is showing must hold at least one of them;
• Required permission(s) — the person looking must hold every one of them.

Leave both empty and the widget is always shown. Fill both and the card appears only when the contact holds a required role and the viewer holds every required permission.

Overriding library defaults

Display options set on a placement override the library's defaults on that page only. That is a separate permission: without it, the override fields are not offered and the message says so.

Advanced (JSON)

Anything the controls above do not cover can be typed as raw configuration. The controls win for every key you touched with them.