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 at the Space or Group layer 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 (/admin/widget-builder): its data selections, source, columns, display options and filter. Everything about it, kind by kind, is on Widgets: the full guide. 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.
• Group — everyone in the permission group you pick sees it, unless they have a personal layer of their own. Pick the group next to the scope. It needs the same permission as Space.
• Space — everyone in the space sees it, unless a group they belong to has a layer, or they have a personal layer of their own.
• Global — every space (super-admin only).

So a person sees their own layout if they made one; otherwise the layout of their group; otherwise the space's; otherwise the built-in one. "Their group" means the permission groups they belong to, including the groups those include.

Group layouts and their order

A page can have a layout for several groups. The Group layouts of this page strip under the toolbar lists them in an explicit order: when a person belongs to several groups that each have a layout, the first one in that order wins — the designer never picks by name or by chance, and never shows a mixture. Move a group up to give it precedence. A new group layout always starts last.

A group's layout starts the moment you place or hide a widget at the Group scope; Edit on a row switches the scope to that group so you see the page exactly as its members do. Remove layout deletes the group's whole layout — every row it holds — and its members fall back to the space's layout. The line above the strip says which layer you would see on this page.

Each row in the table shows its Effective layer (a group row names the group), so you can always see whether what you are looking at is yours, a group's, 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.

Layout variants

A detail page — Contact Detail, say — can open with a different layout depending on the record shown: one for clients, one for agencies, one for "state is NY and role is DSP". Each of these is a layout variant: a condition on the record, written in the same filter builder the contact lists use, and a page of its own (contact_detail.client) that carries its layout.

The Layout variants of this page strip sits under the group-layouts strip on every detail page. It lists the variants in order: when a record opens, the variants are asked from the top, and the first one the record matches wins; a record that matches none opens with the base layout, exactly as before. Each row shows the label, the slug, the condition in words, whether it belongs to this space or to every space, and a warning when the condition no longer works (a column was removed) or names a field some people may not read — those people simply get the next layout that matches, never an error. Viewing the strip needs View widget/page designer; changing it needs Add, order and remove a page's layout variants (a permission of its own, so a space can hand out "variants only" without the whole designer).

• + Add variant asks for a label (the slug fills in from it and is fixed once saved — it is in the page's key), the condition, and where to start from: a copy of this page's current layout at this layer (the space's rows — never a group's or a person's), or an empty page. A person's own Just me layout of the base page does not carry over; a variant is a page of its own.
• Move up / Move down change the order (the first match wins).
• Edit layout opens the variant's own page in the designer — the picker shows it as Contact Detail › Client — where you place, hide and arrange widgets exactly as on any page, at any layer.
• Condition… changes the condition. The save refuses, in words, a condition that does not compile, a condition on a field you may not read, a slug already taken, a page that is not a detail page or is itself a variant, and more variants than the setting widget_page_variants_max allows.
• Turn off stops a variant from being asked; nothing is removed, and Turn on brings it back as it was.
• Delete… removes the variant and its layout — its page, every group's and person's layout of it, its placements and its views. Before it does, the designer tells you how many of each will go, and every removed row is copied whole into the audit log first (a delete whose backup cannot be written removes nothing). Prefer Turn off while you are unsure.

Which layout would this contact get? The preview box under the strip takes a record (pick a contact by name) and shows, for each variant in order, match, no match, cannot be judged for you (the condition names a field you may not read), not visible to you (the condition matched, but the variant's page needs a permission you do not hold, or its own visibility rule hides it), or condition broken with the reason — and the sentence "This contact would open with: Client (contact_detail.client)" or "…the base layout". It judges with your own rights, the same way the page itself does. On the record's own page, a designer sees Layout: Client beside the view picker; nobody else sees anything new.

Preview as… With the permission Preview a page's layout variants as another user (a read of its own — space administrators have it; a space may give it to a designer's group without any power to act as anyone), the preview box gains a user picker. Pick a colleague and the same rows are judged again with their rights, in the third person: match, no match, cannot be judged for them (the condition names a field they may not read — so for them it is a no-match, and they get the next layout), not visible to them (the variant's page needs a permission they do not hold, or its own visibility rule hides it for this record), or condition broken; the sentence becomes "This contact would open, for Lev, with: Client (contact_detail.client)". A colleague who could not open the record at all is answered "This user cannot open this record" and no rows are judged. The preview shows exactly what it would show them and nothing about them: never their permissions, never which field a condition could not reach — one answer per variant and whether the record opens. Nothing changes hands: no session, no login, no audit row in their name; you remain the person acting. The picker lists the users of this space and needs the ordinary View users of this space permission; without it the box says so in words and your own preview still works. Clear the picker and the box is back to your own rights.

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.

The map

Beside the list of placements sits a map of the page: one rectangle for each widget, drawn where it sits on the grid — its column, row, width and height — each in its own colour and with its name inside (hover a rectangle for the full name and its place). On a phone the map sits under the list.

• Overlaps stay visible. The rectangles are see-through, so two widgets that partly cover each other both show; when any two overlap, the map also says so in words under it — 2 widgets overlap: Open deals and Pipeline.
• Tabs are one rectangle. Widgets on exactly the same place (see Tabs below) are drawn as one rectangle named by its tabs in their order — Open deals | Pipeline — and are not called an overlap. Pointing at any of their rows lights that rectangle; clicking it lights all their rows. A widget you turned off is not a tab: it keeps its own striped rectangle (two turned-off widgets on one place are two striped rectangles, as the list shows no tabs for them).
• A tab group shows one tab at a time, like the page: the first tab, until you point at (or tab into) one of its rows in the list — or a widget inside it — or click a tab's name on the rectangle. The shown tab's name is underlined, and hovering the rectangle says tabs — showing Pipeline. When the shown tab is a section, its widgets are drawn inside the rectangle on the section's own grid, each with its name, lighting both ways like any other.
• Inside a hidden section, widgets on exactly the same place are one hatched rectangle named A | B — the list marks them as tabs too; the page draws nothing there until the section is shown again.
• Sections are outlined boxes with their widgets drawn inside, on the section's own grid.
• Hidden widgets and sections are drawn striped and faded, never left out — so is a widget whose section is gone.
• Pointing at a row lights its rectangle; clicking a rectangle lights its row and scrolls to it. The rectangles can be reached with the keyboard too.
• It follows what you edit. The Configure dialog shows the same map, so a rectangle moves as you type its numbers, before you save. Save layout as view… shows it under its table for the view, and for each screen size — the Phone tab draws one column, in order, the way a phone shows the page.

Tabs

Put two or more widgets on exactly the same place — the same column, row, width and height, in the same grid (the page, or one section) — and the page draws them as one box with tabs. That is not an overlap: the designer does not warn about it, and while you configure a widget it says Exactly the same place as … — they are drawn as one box with tabs. Widgets that only partly cover each other, and widgets with no row and column of their own, are never grouped.

• Each tab is named by the widget's label, or by its kind when it has none. The tabs go in the widgets' order; in the table each member's row says Tabs: A | B in that order, and its up and down arrows move it among the tabs.
• Only the open tab's widget is shown — the others are not drawn and load nothing until someone opens them. Each person's browser remembers which tab they had open on that page.
• Who sees what. A widget someone may not see is left out before the tabs are made; if only one is left, it is shown as a plain widget with no tabs.
• Height. The box is forced (fills its share and scrolls inside) when any of its widgets is forced or is a section; a section in a tab keeps its own scroll box. For the row heights it is one widget at its place: its rows are as tall as their own widgets, the same as for a plain widget.
• Everywhere. Saved views and their phone, tablet and desktop layouts group the same way, and on a phone the tabs stay one box in the stack. The home page's own layout editor marks the cards that will be tabs.
• Move out on a member's row puts it on the first free row below the box, so it is drawn on its own again.
• Keyboard: the arrow keys move between tabs, Home and End jump to the first and last.

Sections

A section is a box on the page that holds widgets and has its own scroll bar. Place widgets in it and they sit inside the box, on the box's own grid; when they do not fit, the box scrolls — the page does not move. Sections can sit inside sections.

Adding one. Press + Add section (beside + Place widget). Give it a Label — the Key fills in from it and is fixed once you save, because the widgets in the section point at that key. In section puts it inside another section, or leaves it on the page grid. Its Position is the same four grid fields as a widget's. A section always fills its share and scrolls inside, so there is no force-height box.

Putting widgets in it. Open Configure on a widget and pick the section under In section. The widget keeps its column, row, width and height — they now count in the section's own grid. The table lists each section with its widgets indented under it; the In section column says where each one sits, and the up and down arrows move a widget among the others in the same section. A section with nothing in it says (empty).

Its height — one of three:

• Rows — the Height field above, in rows of the grid it sits in.
• Pixels — a fixed height, at least the minimum row of the grid it sits in.
• Fill what is left — the section takes whatever height is left of the window (or of the section it sits in) and scrolls inside, so the page never scrolls. One section per level can fill.

For fill what is left to keep the page still, everything else beside that section needs a fixed height — force height, pixels, or a section. If something beside it can grow with its content, the designer says this page may still scroll: the page then scrolls when that item grows too tall, because nothing else can make room.

Its inner grid — columns, gap, minimum row, maximum row and uniform rows, exactly like Page settings. Leave a field empty and it inherits from the grid the section sits in. Looks: plain is an invisible layout box; card is a box with the label as its title.

On a phone a section stacks its widgets one under the other and the page scrolls — the same as every widget page on a phone. Switch On phones to keep the scroll box only for a section that must stay a box there; a scroll box inside a scrolling page is harder to use by touch.

Hiding. A section has the same Visibility as any widget. A hidden section hides everything in it — a widget is never shown outside its section, so whoever may not see the section sees none of its widgets either.

Removing. A section's row offers Remove section… instead of Remove override. The dialog names how many widgets it holds and asks what happens to them: Move them to the page grid (the default — every widget stays, at the same position, on the grid the section was in; for a section inside a section, that is the outer section) or Remove them too (when it holds sections of its own, this choice counts everything inside them too — Remove them too — 6 items in all). Either way it is one step: it all happens or nothing does, and the audit log keeps a full copy of every row as it was. A widget whose section is gone says so — its section is gone — move it or remove it — with a button for each. On the home page's own layout editor a section card has no ✕: sections are added and removed here.

Saved views carry sections too: Save layout as view… has an In section column, so a view can move a widget into or out of a section, hide a section (its widgets go with it) or change how tall it is.

Page settings: how rows behave

Page settings… controls the whole page's row behaviour. Whatever you choose, a row is as tall as the tallest widget in it — a widget that spans several rows shares its height among them — and a widget never changes the height of a row it is not in. A tall widget far down the page (say at row 31) leaves row 1 exactly as tall as row 1's own widgets.

• Uniform rows — widgets that share rows align to proportional rows, so a 2-row widget is exactly two-thirds the height of a 3-row neighbour. Content scrolls inside its share. Rows that widgets tie together this way (a widget spans from one into the next) are equalized among themselves only; a row no widget ties to them keeps its own height. A saved view with a fixed number of rows (its 12 × 24 grid) works the same way.
• Minimum row height — a floor in pixels, not a fixed size: rows still grow with their content. An empty row is this tall.
• Maximum row height — a ceiling in pixels; a capped row scrolls its content, and a widget with free rows under it may spill into them before it scrolls. Empty or 0 means no limit. It has no effect when uniform rows are on.
• 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.

A role's Hidden when rule (set in the Role designer) only hides its chip and its name in lists — it never affects Required role(s): a contact who holds a hidden role still passes that condition.

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.