Most users land on the home screen at the start of every session. It's the first thing they see, the one surface that sets the tone of the application for them every working day. A static welcome banner that says "Hello" and nothing else wastes that attention. A role-aware dashboard spends it well: today's tasks and unread messages for an operator, overdue invoices and this month's revenue for an accountant, pipeline health and this week's new opportunities for a sales manager. Homepage widgets are how that personalization happens — without any per-role custom development.
A widget is a placeable block on the home screen. Some widgets are canvas-built, which means they're constructed with the full expressiveness of the canvas page builder — data bindings, queries, iterators, conditional rendering, the whole palette. Others are pre-defined — shortcuts for common patterns that a new tenant can drop in without configuring. A mix of both is the typical setup: a few standard widgets for the common needs, a handful of canvas widgets tailored to the tenant's own data.
Per-role visibility is where the dashboard becomes genuinely useful. Widgets can be assigned to one or more roles, and users see the widgets their roles permit. A salesperson's homepage shows deal cards, a pipeline chart, and a list of recent mentions. An accountant's shows overdue invoices, a cash-flow summary, and the month's new customers. A support lead's shows open tickets by age, a queue depth chart, and today's team presence. Same home screen, same page component, four completely different lived experiences — because widgets respect role assignment.
Per-user arrangement gives individual users a small amount of personalization within the set their role permits. The widgets they see aren't negotiable — those are controlled by the role — but the order they appear in and the space each one takes can be adjusted. Edit-dashboard mode is toggled from the top bar; users drag, resize, and save; the next time they open the home screen, the arrangement is theirs. The constraint is important: users can't add widgets outside their role's allowance, because that would bypass the permission model. But within that allowance, they can make the dashboard fit their actual workflow.
Edit-dashboard mode for admins is a parallel feature with a different audience. Administrators configure which widgets are available to which roles, set their default layout, and preview how each role's dashboard looks. That's the canonical surface for designing the per-role landing experience — not a scattering of configuration files, a single editor where the choices and their consequences are visible together.
Canvas-built widgets are where the flexibility lives. Because a widget can be built from the same blocks as any other canvas page, the only real constraint is the widget's allotted space. Summary cards with counts and trends. Compact table views of the most urgent records. Iterators over the user's own tasks. Charts, when a small visualization makes a point quickly. Filter controls that affect what the rest of the dashboard shows. An onboarding checklist for new users with conditional items that disappear as they're completed. If you can imagine a small, focused piece of dashboard UI, canvas can build it.
Widget defaults per role are the small but important touch that makes new users productive on day one. When a user joins a role, their dashboard starts with the role's default widget set already in place. They're not staring at an empty screen, wondering how to configure themselves; they're looking at the same dashboard their colleagues in the same role are using. They can personalize from there, but the starting point is already reasonable.
Custom head elements per widget handle the edge cases where a widget needs its own CSS or scripts. A complex visualization, an embedded external tool, a specialized interactive component — all of these sometimes need head-level contributions that shouldn't apply to the whole application. Head elements scoped to a widget let that work happen cleanly, within the platform's security boundaries (the rich-text allow-list and the canvas sandbox rules).
Widgets and permissions behave the way permissions behave everywhere else: if a widget surfaces data the current user can't see, the data isn't surfaced. A widget showing overdue invoices shows only the invoices the viewer has access to. A widget listing open tasks shows only the tasks assigned to people the viewer can see. The widget definition doesn't have to know about permissions; the underlying queries enforce them, and the widget inherits that enforcement automatically. That's what makes it safe to put the same widget definition in front of users with different access — the data the user sees is still the data they're allowed to see.
For tenants with tile-based navigation on the homepage — a simple grid of module shortcuts for users who think of their work as "which area of the app am I in today?" — widgets coexist naturally. Tiles handle navigation; widgets handle summaries and actions. A mixed homepage with both feels right for a lot of audiences: the tile row at the top for jumping to areas, a widget grid below for the at-a-glance information that the user wants before they jump.
Worked example: "today's open tasks." A canvas widget bound to a saved query for the user's open tasks due today or earlier, rendering each task as a compact card with its title, due date, and a quick-action button to mark it complete. One query, one template, deployed to every user's home screen. Each user sees only their own tasks because the query references currentUser. The quick-action button triggers an automation that updates the task. The widget re-renders after the action completes, and the task disappears from the list. Zero custom code; this is entirely configuration.
For many tenants, homepage widgets are the feature that moves the platform from "a tool we use when we need it" to "where the day starts." That framing matters. A good homepage is what keeps users in the application rather than toggling out to check what's happening in three other systems. We'd rather the platform be the summary than redirect people to it.